Method and apparatus for operating networked gaming devices

ABSTRACT

A system for monitoring and configuring gaming devices interconnected over a high-speed network is disclosed. The system can support a file server, one or more floor controllers, one or more pit terminals, and other terminals all interconnected over the network. Each gaming device includes an electronic module which allows the gaming device to communicate with a floor controller over a current loop network. The electronic module includes a player tracking module and a data communication node. The player tracking module includes a card reader for detecting a player tracking card inserted therein which identifies the player. The data communication node communicates with both the floor controller and the gaming device. The data communication node communicates with the gaming device over a serial interface through which the data communication node transmits reconfiguration commands. The gaming device reconfigures its payout schedule responsive to the reconfiguration commands to provide a variety of promotional bonuses such as multiple jackpot bonuses, mystery jackpot bonuses, progressive jackpot bonuses, or player specific bonuses.

BACKGROUND OF THE INVENTION

[0001] This invention relates generally to gaming devices, and moreparticularly to a method and apparatus for controlling gaming devicesinterconnected by a computer network.

[0002] Networked gaming devices are know in the art. Interconnecting aplurality of gaming devices such as slot machines via a computer networkto a central computer provides many advantages. The primary advantage ofnetworked gaming devices is the ability to extract accounting data fromthe individual gaming devices as well as providing player tracking. Anexample of a data collection system is described in U.S. Pat. No.

issued to Lucero et al. Network systems such as described in Lucero etal. allow the central host computer to monitor the usage and payout,collectively known as audit data, of the individual gaming devices. Thisaudit data includes data related to the number of coins or tokensinserted into the device, the number of times the device has beenplayed, the amount paid in raises, the number and the type of jackpotspaid by the machine, the number of door openings, etc. The host computercan then compile an accounting report based on the audit data from eachof the individual gaming devices. This report can then be used bymanagement, for example, to assess the profitability of the individualgaming devices.

[0003] Player tracking, as the name indicates, involves trackingindividual player usage of gaming devices. In prior art player trackingsystems, the player is issued a player identification card which hasencoded thereon a player identification number that uniquely identifiesthe player. The individual gaming devices are fitted with a card reader,into which the player inserts a player tracking card prior to playingthe associated gaming device. The card reader reads the playeridentification number off the card and informs a central computerconnected thereto of the player's subsequent gaming activity. Bytracking the individual players, individual player usage can bemonitored by associating certain of the audit data with the playeridentification numbers. This allows gaming establishments to targetindividual players with direct marketing techniques according to theindividual's usage.

[0004] One problem that can occur with current player tracking systemsis that the player can insert a player identification card incorrectlyunbeknownst to the player. Currently, if a player inserts a playeridentification card improperly into the card reader, a message appearson a display located away from the card reader. Unfortunately, theplayer may not be looking at the display while inserting the card. As aresult, the player may not see the message on the display. Another priorart approach has been to provide a light emitting diode on the gamingdevice to indicate to the player the status of the card insertion. Thistoo has been ineffective because the player may not know the purpose ofthe LED or the LED may be drowned out by all the other lights of thecasino. The player may therefore commence playing with the cardimproperly inserted. In this case, both the player and the casino losevaluable player tracking information. This is frustrating for the playerbecause his activity will not be credited to his account and frustratingfor the casino because the casino's records will be incomplete.Accordingly, a need remains for an improved method and apparatus forinforming the player when a player tracking card has been improperlyinserted.

[0005] The full power of networked gaming devices has not beencompletely realized. Although the audit data indicates which devices arebeing under utilized and when, there is currently no automated methodfor altering under utilized gaming devices' configurations to make themmore attractive to play. For example, during certain hours of the day,e.g. four to six a.m., the audit data may indicate that the machines arebeing under utilized. Thus, it would be desirable to reconfigure theunder utilized gaming devices to provide an additional incentive toplayers to use these devices. In the past casinos have run “bonuses”during these times. An example of such bonuses include a “doublejackpot” wherein a player hitting a jackpot is paid double the jackpotamount. Currently this is implemented by having an attendant manuallypayout the additional payout amount. This manual technique, however, iscumbersome and inefficient to administer because an attendant must beconstantly supervising the bonusing gaming devices. Accordingly, a needremains for an automated method and apparatus to provide bonusing forgaming devices.

[0006] Another limitation of the current bonusing systems is that onlypredetermined machines are eligible for the bonusing. For example, in aprogressive bonusing machine a plurality of machines are connectedtogether to form a bank. Only the machines in the bank are then eligibleto win the progressive jackpot. Thus, a casino must dedicate a certainnumber of its machines to these banks. This limits the casino'sflexibility in tailoring its bonusing to the number and make-up of itscustomers. Accordingly, a need remains for a more flexible bonusingsystem whereby any of the casino's machines can participate in thebonusing.

SUMMARY OF THE INVENTION

[0007] It is, therefore, an object of the invention to reconfiguregaming devices remotely over a network to provide bonusing.

[0008] Another object of the invention is to provide an integratedsystem usable with a variety of gaming devices made by differentmanufacturers.

[0009] Another object of the invention is to integrate player tracking,data collection, and bonusing over the same network.

[0010] A further object of the invention is to provide visual feedbackto the user when a player tracking card has been improperly inserted.

[0011] A system for operating networked gaming devices is described. Thesystem according to the invention allows a casino in which the system isinstalled to run promotions or bonuses on any properly equipped gamingmachines while simultaneously gathering player tracking and accountingdata from all machines. The system provides the capability for thecasino to select which of the plurality of machines are used in anygiven promotion. The system further allows any number of differentpromotions to operate simultaneously.

[0012] The system includes a plurality of gaming devices or machinesconnected to an associated floor controller over a network. The systemincludes one or more of said floor controllers. The floor controllersare interconnected by a high-speed network, such as an Ethernet network,to a database where accounting and player tracking data is stored. Thesystem can also include pit terminals and/or fill and jackpot processingterminals. Each promotion involves sending a reconfiguration commandfrom the floor controller to a gaming device that has been selected tobe part of a given promotion over the associated network. Upon receiptof the reconfiguration command, the gaming device reconfigures itspayout schedule in accordance with the received reconfiguration command.In the preferred embodiment, this reconfiguration includes activating abonus payout schedule. A partial list of the promotions according to theinvention include, but are not limited to: a multiple jackpot whereinthe gaming device reconfigures its payout to be a multiple of itsdefault payout schedule; a bonus jackpot wherein the gaming devicereconfigures its payout schedule to payout an additional bonus amountwhen certain conditions are met; and a progressive jackpot wherein twoor more gaming devices are combined in a progressive jackpot having aprogressive jackpot payout schedule. In addition to these, many otherpromotions are possible by the above-described system for controllingand monitoring a plurality of gaming devices.

[0013] The system also allows for improved player tracking by recordingeach and every machine transaction including time of play, machinenumber, duration of play, coins in, coins out, hand paid jackpots andgames played. The player tracking is conducted over the same network asthe accounting data is extracted. This allows the invention to providebonusing to certain individual players as well as during certain times.As with standard player tracking, the above-described system monitorsand reports how many coins are played by each player. The systemaccording to the invention, however, also includes the ability to recordhow long each player spends at each machine and the number of coins won,games played, and hand jackpots won by each player. The invention isable to record all this information because the system operates on atransaction by transaction basis. Each transaction, whether it be a coinin, a handle pull, etc., is recorded by the system. Other systems simplycompile the player tracking information at the completion of play. Allthis information is stored on the database, which can be later analyzedfor future targeted direct mailing campaigns. The player trackingaccording to the invention also allows the casino to schedule buses andother groups and measure their profitability. The system also allows forcashless play as well as advanced accounting and security features.

[0014] An advantage of the invention is that any of the casino'smachines can be incorporated into a bonus promotion.

[0015] Another advantage of the invention is that several bonuspromotions can operate simultaneously.

[0016] A further advantage of the invention is the ability to recordeach and every machine transaction including time of play, machinenumber, duration of play, coins in, coins out, hand paid jackpots andgames played.

[0017] A further advantage of the invention is the ability to associatea player with a certain machine.

[0018] A further advantage of the invention is the ability to performmore targeted direct mailing based on individual play.

[0019] A further advantage of the invention is the ability to calculatea theoretical win exactly.

[0020] A further advantage of the invention is the ability to generatejackpot announcements, which provides for, among other things, betterslot tournaments.

[0021] A yet further advantage of the invention is the ability toquickly and easily add new machines to the network.

[0022] The foregoing and other objects, features and advantages of theinvention will become more readily apparent from the following detaileddescription of a preferred embodiment of the invention which proceeds iswith reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0023]FIG. 1 is an illustration of a system for monitoring andconfiguring gaming devices according to the invention.

[0024]FIG. 2 is a block diagram of an electronic module associated witheach gaming device to permit monitoring and configuring thereof.

[0025]FIG. 3 is a schematic diagram of a data communication node of theelectronic module of FIG. 2.

[0026]FIG. 4 is a schematic diagram of a discrete machine interfacecircuit of the electronic module of FIG. 2.

[0027]FIG. 5 is a schematic diagram of a player tracking module of theelectronic module of FIG. 2.

[0028]FIG. 6 is a schematic diagram of a card reader circuit of theelectronic module of FIG. 2.

[0029]FIG. 7A is an exploded view of a card reader according to theinvention.

[0030]FIG. 7B is a rear perspective view of the card reader of FIG. 7A.

[0031]FIG. 7C is a front perspective view of the card reader of FIG. 7A.

[0032]FIG. 8 is a schematic diagram of a display circuit of the playertracking module of FIG. 2.

[0033]FIG. 9 is a schematic diagram of a personality board of theelectronic module of FIG. 2.

[0034]FIG. 10 is a schematic diagram of a triac driver circuit of theelectronic module of FIG. 2.

[0035]FIG. 11 is a schematic diagram of a relay driver circuit of theelectronic module of FIG. 2.

[0036]FIG. 12 is a block diagram of a communication board included ineach floor controller of FIG. 1.

[0037]FIG. 13 is a flow chart for the power-on procedure for the datacommunication node (DCN) of FIG. 2, which is implemented in firmwareexecuted by the DCN controller.

[0038]FIG. 14 is a flow chart for processing of the discrete gamingdevice inputs, of FIG. 13.

[0039]FIG. 15 is a flow chart for the step of incrementing meter countsassociated with each gaming device of FIG. 14, which is implemented infirmware executed by the DCN controller.

[0040]FIG. 16 is a flow chart for the step of processing the serialinterface between the gaming device and the data communication node ofFIG. 13, which is implemented in firmware executed by the DCNcontroller.

[0041]FIG. 17 is a flow chart for the step of processing the networkinterface between the floor controller and the data communication nodeof FIG. 13, which is implemented in firmware executed by the DCNcontroller.

[0042]FIG. 18 is a flow chart for the step of processing the networkmessage of FIG. 17, which is implemented in firmware executed by the DCNcontroller.

[0043]FIG. 19 is a flow chart for the step of processing the datacommunication node request of FIG. 18, which is implemented in firmwareexecuted by the DCN controller.

[0044]FIG. 20 is a flow chart for the step of FIG. 13 of processing theplayer tracking interface, which is implemented in firmware executed bythe DCN controller.

[0045]FIG. 21 is a flow chart for the step of processing a validinserted card of FIG. 20, which is implemented in firmware executed bythe DCN controller.

[0046]FIG. 22 is a flow chart for the step of processing player trackinginformation of FIG. 21, which is implemented in firmware executed by theDCN controller.

[0047]FIG. 23 is a flow chart for the power-on procedure for the playertracking (PT) node of FIG. 2, which is implemented in firmware executedby the PT controller.

[0048]FIG. 24 is a flow chart for the step of processing the DCNinterface of FIG. 23, which is implemented in firmware executed by thePT controller.

[0049]FIG. 25 is a flow chart for the step of processing the DCN messageof FIG. 24, which is implemented in firmware executed by the PTcontroller.

[0050]FIG. 26 is a flow chart for the step of processing the card readerbezel update of FIG. 23, which is implemented in firmware executed bythe PT controller.

[0051]FIG. 27 is a flow chart for the step of processing the card readerof FIG. 23, which is implemented in firmware executed by the PTcontroller.

[0052]FIG. 28 is a flow chart for the power-on floor controller process,which is implemented in software executed by the floor controller.

[0053]FIG. 29 is a flow chart for the message processing step of FIG.28, which is implemented in software executed by the floor controller.

[0054]FIG. 30 is a flow chart for the message handling step of FIG. 29,which is implemented in software executed by the floor controller.

[0055]FIG. 31 is a flow chart for the step of assigning unique machineaddresses of FIG. 30, which is implemented in software executed by thefloor controller.

[0056]FIG. 32 is a flow chart for the system monitoring step of FIG. 28,which is implemented in software executed by the floor controller.

[0057]FIG. 33 is a flow chart for the event handling step of FIG. 32,which is implemented in software executed by the floor controller.

[0058]FIG. 34 is a flow chart for bonus control, which is implemented insoftware executed by the floor controller.

DETAILED DESCRIPTION

[0059] Table of Contents I. SYSTEM ORGANIZATION A. SYSTEM OVERVIEW B.DATA COMMUNICATION NODE 1. OVERVIEW 2. CONTROLLER AND MEMORY 3. NETWORKINTERFACE 4. SERIAL MACHINE INTERFACE 5. SERIAL DISPLAY INTERFACE 6.DISCRETE MACHINE INTERFACE 7. MACHINE CONFIGURATION C. PLAYER TRACKINGMODULE 1. OVERVIEW 2. SERIAL DISPLAY CIRCUIT 3. SERIAL EXPANSION PORTS4. CARD READER 5. DISPLAY 6. DISCRETE INPUT SECTION D. PERSONALITY BOARDE. BONUS DISPLAY DRIVERS F. FLOOR CONTROLLER II. OPERATION A. DATACOMMUNICATION NODE 1. POWER UP PROCEDURE 2. READING UNIQUEIDENTIFICATION NUMBER 3. MONITORING GAMING DEVICE DISCRETE INPUT 4.PROCESSING GAMING DEVICE SERIAL INTERFACE 5. PROCESSING NETWORKINTERFACE 6. PROCESSING PLAYER TRACKING INTERFACE 7. PROCESSING CARDINSERTION B. PLAYER TRACKING MODULE 1. POWER UP PROCEDURE 2. PROCESSINGDCN INTERFACE 3. PROCESSING DISPLAY UPDATE 4. PROCESSING BEZEL UPDATE 5.PROCESSING CARD READER C. FLOOR CONTROLLER 1. POWER UP PROCEDURE 2.MESSAGE PROCESSING 3. ASSIGNING GAMING DEVICE ADDRESSES 4. SYSTEMMONITORING 5. BONUS CONTROL

I. System Organization

[0060] A. System Overview

[0061] A system for operating a plurality of gaming devices is showngenerally at 10 in FIG. 1. The system, hereinafter described, monitorsand reconfigures a plurality of gaming devices or machines 12-16 and22-26. The system includes the following capabilities: remotereconfiguration, accounting data extraction, integrated player tracking,and cashless play. Remote reconfiguration includes sending areconfiguration command from a host computer to one or more of thegaming devices. The gaming devices, on receiving a reconfigurationcommand, will reconfigure its jackpot payout schedule in accordance withthe reconfiguration command.

[0062] This reconfiguration, in the preferred embodiment, comprisesactivating a bonus payout schedule. This bonus payout schedule is inaddition to the normal pay table of the gaming device. The bonus payoutschedule provides for additional bonus payouts in addition to thepayouts specified by the device's normal pay table. The differencebetween the two is important for regulatory reasons. The composition ofthe pay table is subject to regulation by the various state gamingcommissions while the bonus payout schedule is not. The preferredembodiment currently activates only the bonus payout schedule responsiveto the reconfiguration command, while not altering the payout table. Theinvention, however, is not limited to activating only the bonus payoutschedule. Other embodiments, which would be subject to regulatoryapproval, could modify the device's payout table. The preferredembodiment, however, does not.

[0063] The system, according to the invention, implements a variety ofbonusing events through this reconfiguration process. These bonusingevents include: a multiple jackpot wherein the gaming devicereconfigures its payout to be a multiple of its default payout schedule;a bonus jackpot wherein the gaming device reconfigures its payoutschedule to payout an additional bonus amount when certain conditionsare met; and a progressive jackpot wherein two or more gaming devicesare combined in a progressive jackpot having a progressive jackpotpayout schedule.

[0064] The system, according to the invention, also provides forintegrated player tracking and accounting data extraction. Unlike priorart systems that use disparate systems for player tracking andaccounting data extraction, the system 10 provides for player trackingand accounting data extraction over the same network. The playertracking, according to the invention, allows the casino to run certainpromotional events. The integrated player tracking and accounting dataextraction also allows the system to support cashless play wherein acredit is given to a player over the network.

[0065] The system 10 includes one or more floor controllers 18 and 28.Each floor controller supports up to a predetermined maximum number ofgaming devices. In the preferred embodiment, each floor controller cansupport up to 1024 gaming devices. The preferred embodiment alsosupports up to eight floor controllers. Thus, the system 10 can supportup to 8192 separate gaming devices.

[0066] The system supports a multiplicity of various gaming devices. Thegaming devices 12-16 and 22-26 shown in FIG. 1 are the type having apull handle for initiating a game, e.g., slot machines. However, theinvention is not limited to such gaming devices. The gaming devicesshown in FIG. 1 can also be gaming tables or push button operatedmachines as well, e.g, video poker. As will be described hereinafter,the system supports any gaming device providing traditional discreteconnections, e.g., coins-in, coins-out, etc., as well as those havingserial interfaces, as described below.

[0067] The floor controllers 18 and 28 are, in the preferred embodiment,IBM-compatible personal computers. Each floor controller is responsiblefor monitoring the activity level of the corresponding gaming devicesconnected thereto and issuing commands to the associated gaming devicesto reconfigure their payout schedules during certain bonusing events.The floor controllers issue status requests to each of the individualgaming devices to determine the activity level of each. In the event thefloor controller detects any activity, the floor controller communicatesthat activity to a file server 32, which is connected to the floorcontrollers via a high speed network 38 connected therebetween.

[0068] In the preferred embodiment, the file server 32 includes a highperformance personal computer or work station having a large hard diskcapacity in order to store the gaming device activity therein. In thepreferred embodiment, the high speed network 38 is a ten megabyteethernet network. The system 10 also includes commercially availablenetwork software to support the industry-standard ethernet network 38.An example of such network software is Novell network software sold byNovell of Provo, Utah. The file server 32 also includes a databaseprogram by which reports can be generated using the data stored on thefile server. Such reports include, e.g. area, model, denomination andsummary reports. The database software also allows a user to generatecustom reports. The database software is based on the industry-standardParadox database language.

[0069] The system 10 also includes a pit terminal 34 which is alsoconnected to the ethernet network 38. The pit terminal 34 is also astandard personal computer, in the preferred embodiment, and can be usedto monitor the gaming device activity in the pit. This terminal 34 canalso be used as a security monitoring device to detect any unanticipatedevents like fills or payouts.

[0070] The system 10 further includes any number of fill and jackpotprocessing terminals 36. These terminals 36 are placed in the cageand/or the change booth areas of the casino for fill and hand-paidjackpot processing. When a fill is required, a floor person goes to thenearest cashier's booth and states the gaming device number requiring afill. The booth attendant enters the number into the fill and jackpotprocessing terminal 36 located in the cashier's booth. The terminal 36then looks up the record associated with the particular gaming device inthe file server 32 to determine the correct fill amount. The terminal 36also calculates a theoretical hopper balance for the particular devicebased on the latest meter information, as described further below. Ifthe calculation shows a significant hopper balance, a warning is givenon the computer screen from which security can then be alerted.

[0071] A fill and jackpot processing terminal 36 prints a fill ticketupon demand. If the calculated hopper balance was nearly zero, theterminal 36 cause the words “computer verified” to be printed on theticket in place of a supervisor's signature. In the event that thecalculated hopper balance was not near zero, an extra signature isrequired to complete the fill transaction. The system follows a similarprocedure for processing hand-paid jackpots.

[0072] A dispatch station (not shown) can also be included in thesystem. The dispatch station allows the casino to monitor activity onthe gaming devices and “run the casino” from one location. The dispatchstation allows the dispatcher to monitor customer service, maintenance,and security events and direct other casino personnel to handle thesesituations appropriately. For example, during hopper empties (fills) andjackpot events, as indicated by the dispatcher station, the dispatchercould radio down to the floor to have someone verify the event. Thedispatcher station can also indicate when a machine door is openedwithout a technician card inserted, for example, in which case thedispatcher could take the appropriate course of action.

[0073] The above-described system 10 is but one embodiment of the systemaccording to the invention. The system tasks can be allocated in avariety of ways amongst the system computers including floor controllers18 and 28, file server 32, pit terminal 34 and fill and jackpotterminals 36. In some cases, the pit terminal 34 and fill and jackpotterminals 36 can even be eliminated and their tasks allocated to thefloor controller or file server. In fact, because the file server 32 isessentially a virtual hard disk for the floor controllers 18 and 32, thefloor controllers and the file server can be considered a single hostcomputer for the system 10.

[0074] B. Data Communication Node

[0075] 1. Overview

[0076] In order to communicate with the floor controller, each gamingdevice includes therein an electronic module 40, as shown in FIG. 2.This module 40 can be inserted into a variety of pre-existing gamingdevices. The module allows the host computer to uniquely identify thegaming device on the network, including the device type. The module 40includes two main subcomponents: a data communication node 42 and aplayer tracking module 44. The data communication node 42 keeps track ofthe coins-in, coins-out, coins to drop, games played, jackpotoccurrences and other related functions of the associated gaming device.The player tracking module 44 keeps track of the player that is playingthe associated gaming device. Together, the data communication node 42and the player tracking module 44 allow the floor controller connectedto the associated gaming device to monitor and control the activity ofthe gaming device. The system hereinafter described in detail includesthe following capabilities: slot accounting, player tracking, bonusjackpots and cashless play.

[0077] 2. Controller and Memory

[0078] The data communication node (DCN) 42 includes a datacommunication node controller 46, which in the preferred embodiment isan HD6473258P10 controller manufactured by Hitachi of Tokyo, Japan. TheDCN 42 is coupled to the player tracking controller 44 through businterface logic 45. The bus interface logic 45 is conventional interfacelogic including, for example, transceivers, as is known in the art ofdigital design.

[0079] A memory 48 is connected to the DCN controller 46. The memoryincludes program memory for storing program instructions for the DCNcontroller 46. In the preferred embodiment, this program memory includesa nonvolatile read-only memory (ROM). However, this program memory couldalso be flash or “battery” backed RAM in order for the program memory tobe updated by the floor controller. In the event flash or “battery” backRAM is used the floor controller would download the updated program tothe DCN controller and the DCN controller would overwrite the programmemory with the downloaded program.

[0080] The memory 48 also includes system memory, e.g., staticrandom-access memory (SRAM) for storing the gaming device information.This gaming device information includes at least the following meters:coins-in, coins-out, coins to drop, games played, jackpot occurrences. Aseparate meter counter is kept in memory 48 for each of these values. Toincrease reliability of the data, in the preferred embodiment, aredundant set of these counters is kept in a physically separate memorydevice within memory 48. Moreover, the memory devices storing thesecounters are nonvolatile so that in the event of a power failure thecounts will be retained. The nonvolatile memories can either bebattery-backed SRAM or electrically erasable programmable read-onlymemory (EEPROM). Although memory 48 is shown external to DCN controller46, much if not all of the memory 48 can be included in the DCNcontroller 46.

[0081] 3. Network Interface

[0082] The data communication node 42 also includes a network interface49 for connecting the data communication node 42 to the associated floorcontroller. The network interface is coupled to the floor controllerthrough a personality board 202, described below.

[0083] A more detailed drawing of network interface 49 is shown in FIG.3. In FIG. 3, the DCN controller 46 receives data from the floorcontroller over conductor 52 which is optically isolated from aconnector 51 by optical isolator circuit 54. The DCN controller 46transmits data to the floor controller over conductor 56, which isoptically isolated from the connector 51 by optical isolator circuit 58.Each of the opto-isolator circuits 54 and 58 include an opto-coupler asare known in the art. A bus 222 (FIG. 2) is connected between thenetwork interface 49 and the personality board 202.

[0084] 4. Serial Machine Interface

[0085] Referring to FIG. 2, the data communication node includes aserial machine interface 60. The serial machine interface 60 allows thedata communication node 42 to communicate with the associated gamingdevice advance serial interface as contrasted with the discreteinterface, to be described further hereinafter. A bus 224 (FIG. 2)connects the serial machine interface 60 to the associated gaming deviceat connector 62. The serial interface, in the preferred embodiment, is astandard RS-232 three wire interface.

[0086] Referring to FIG. 3, the DCN controller 46 receives data from thegaming device over conductor 64 which is connected between the DCNcontroller 46 and a differential to single-ended converter 66. The DCNcontroller 46 transmits data to the gaming device over conductor 68connected between the DCN controller 46 and the converter 66. Theconverter 66 converts the differential inputs of the serial interface 62to a single-ended output which is transmitted over conductor 64 to theDCN controller 46. The converter 66 also converts the single-ended inputreceived from the DCN controller 46 to a differential output signal andtransmits that to the serial interface 62. The serial machine interfaceis the means by which the DCN controller communicates certainreconfiguration data, referred to as reconfiguration commands, to themachine. These reconfiguration commands cause the machines to activate abonus payout table to allow the machine to append bonus payments totheir standard jackpot payouts, as specified by their payout table,during certain bonus activities.

[0087] 5. Serial Display Interface

[0088] The data communication node 42 further includes a serial displayinterface 70 illustrated in more detail in FIG. 3. The serial displayinterface 70 includes logic coupled between the DCN controller 46 and anexpansion connector 71. The expansion connector 71 allows the DCNcontroller 46 to communicate with an expansion device connected thereto.

[0089] 6. Discrete Machine Interface

[0090] The data communication node 42 also includes a discrete machineinterface 72, which is shown in detail in FIG. 4. The discrete machineinterface 72 includes a plurality of opto-couplers 78 coupled betweenthe discrete outputs from the gaming device or machine and the DCNcontroller 46. The discrete outputs of the machine are received atterminals 74A-74J of a connector 74 via a cable (not shown) connectedbetween the machine and the connector 74. The discrete outputs arecoupled to corresponding inputs 76A-76J via opto-couplers 78. Thediscrete outputs from the machine include: an EXTRA signal, a POWERsignal, a COIN IN signal, a COIN OUT signal, a COIN DROP signal, aJACKPOT signal, a HANDLE signal, a TILT signal, a SLOT DOOR signal, anda DROP DOOR signal. Each of these signals correspond to a known event inthe machine. For example, when a coin is dropped in the machine a COININ signal appears on terminal 74C. This COIN IN signal is thentransmitted to the DCN controller 46 on line 76C via the associatedopto-coupter.

[0091] All of the signal lines 76A-76J include a pullup resistor and apulldown capacitor, which combined form an RC network on the associatedline. The resistors are, in the preferred embodiment, in the form of aresistor pack 80 and the capacitors are individual discrete capacitors82. Alternatively, the capacitors can be removed for high-speed signals.

[0092] 7. Machine Configuration Circuit

[0093] The data communication node 42, as shown in FIGS. 2 and 3,further includes a machine configuration circuit 84. In the preferredembodiment, as shown in FIG. 3, the machine configuration circuit 84includes a parallel to serial converter 86, which includes eightparallel inputs IN, a serial input SIN, a clock input CLK, a strobeinput STB, and a serial output SOUT. The parallel inputs IN areconnected to a personality board, as described hereinafter, to receive aunique machine configuration number therefrom, which uniquely identifiesthe type of machine that the data communication node is connected to. Inthe preferred embodiment, the machine identification number is comprisedof six bits. Therefore, the two remaining parallel inputs can be used toprovide additional inputs, such as additional discrete machine inputs,to the DCN controller 46.

[0094] The machine configuration number presented on the parallel inputsof the parallel to serial converter 86 is latched therein responsive toa strobe signal received at the strobe STB input. A strobe input isgenerated by the DCN controller 46 on conductor 90 which is coupled tothe strobe STB input. The parallel data is clocked out of the converter86 to the DCN controller 46 on conductor 88 and connected between theserial output SOUT of the converter 86 and an input of the DCNcontroller 46 responsive to a clock signal received on the clock inputCLK of the converter 86. The clock signal is generated by the DCNcontroller 46 and is transmitted to the converter 86 via conductor 92which is coupled between an output of the DCN controller 46 and theclock input CLK of the converter 86.

[0095] The converter 86 also includes a serial input SIN for receivingserial input data. The serial input SIN is coupled to an expansionterminal 94C of expansion connector 94. Conductors 90 and 92 are alsocoupled to the expansion terminal 94 to provide the clock and strobesignals thereto. The expansion terminal 94 therefore provides the meansfor the DCN controller 46 to access additional serial informationthrough the parallel to serial converter 86. In the preferredembodiment, the parallel to serial converter 86 is part number 4021manufactured by Toshiba Corporation of Tokyo, Japan.

[0096] C. Player Tracking Module

[0097] 1. Overview

[0098] Referring again to FIG. 2, the module 40 coupled to each of thegaming devices includes a player tracking module 44. The player tracking(PT) module 44 includes a player tracking controller 98, a card reader100, a serial display driver 101, a display 102, and expansioninterfaces 104 and 106. The player tracking controller 98 communicateswith the data communication node controller 46 through bus interfacelogic 110. The DCN controller 46 and PT controller 98 maintain amaster-slave relationship, respectively. Therefore, all communication isinitiated by the DCN controller 46. The bus interface logic isconventional logic and its design is well-known in the art of digitalelectronics.

[0099] In the preferred embodiment, the player tracking module 44, withthe exception of the card reader 100 and the display 102, resides on asingle printed circuit board, while the data communication node 42resides on a separate printed circuit board. The player tracking module44 and the data communication node 42 are then connected by a cable 111such as a ribbon cable.

[0100] 2. Serial Display Circuit

[0101] A more detailed drawing of the player tracking module 44 is shownin FIG. 5. In FIG. 5, the serial display circuit 101 includes atransistor Q1 and a resistor R1 connected to the base thereof. Aconductor 112 is connected between the PT controller 98 and the resistorRI to provide a drive signal to transistor Q1. The drive signal causestransistor Q1 to conduct a current and thereby drive a display connectedto the collector of Q1 at a terminal 114 of a connector 115. In thepreferred embodiment, the terminal 114 is connectable to a small vacuumflorescent display to provide serial display data thereto.

[0102] 3. Serial Expansion Ports

[0103] The player tracking module 44 also includes two serial expansionports 104 and 106. Each of the expansion ports 104 and 106 includes adifferential to single-ended converter 116 and 118, respectively. In thepreferred embodiment, these converters 116 and 118 are part numberLTC490 manufactured by Linear Technology Corporation of Milpitas, Calif.The PT controller 98 communicates with each converter via twosingle-ended, serial signal lines: an input signal line and an outputsignal line. The converters convert the single ended signals appearingon these lines to differential signals. The differential signals,however, can be used as single-ended signals as is known in the art. Thefirst expansion port 104 interfaces the player tracking node 44 with alarge vacuum florescent display 102 (FIG. 5) used to display playertracking messages, as described further below. The display is connectedto the connecter 115, in the preferred embodiment, by a cable 103. Theother expansion ports 106 provides the player tracking module withfuture expansion capabilities to support additional features.

[0104] 4. Card Reader

[0105] Referring now to FIGS. 6 and 7, the card reader 100 will now bedescribed. FIG. 6 shows the electrical schematic for the card readerwhile FIG. 7 shows the mechanical drawing thereof. In FIG. 7A, anexploded view of the card reader is shown. The card reader includes aplastic bezel 116 having a card reader opening 118 formed therealong forreceiving a card 120 therein. The bezel 116 includes guide rails 122 and124 disposed at opposite, respective lateral ends of the opening 118.The guide rails 122 and 124 have stops 126 and 128, respectively. Theguide rails 122 and 124 guide the card 120 through the opening 118 untilan end of the card 120 contacts stops 126 and 128. The card is shownfully inserted in FIGS. 7B and 7C with the end of the card 120 abuttingthe stops 126, 128.

[0106] The card reader also includes a printed circuit board 130 havinga longitudinal opening to allow the guide rails 122 and 124 to beinserted therein in order to allow the printed circuit board 130 to bepushed up flush against a mounting plate 132 of the bezel 116, as shownin FIGS. 7B and 7C. Mounted on one side of the printed circuit board 130is an array of photodiodes 134 and an array of photodetectors 136. Thephotodiodes 134 are mounted on the printed circuit board along one sideof the opening in the printed circuit board, while the photodetectors136 are mounted on the printed circuit board along an opposite side ofthe opening. The photodiodes and the photodetectors are verticallyaligned in a one-to-one relationship, i.e., one photodiode for eachphotodetector. In the preferred embodiment, the array of photodiodesincludes eight individual diodes spaced equidistance along the openingin the printed circuit board 130. The photodiodes 134 are mounted alongthe opening in the printed circuit board 130 so as to align withseparate rows of openings in the card 120, as described further below.The card reader also includes optional light masks 138 and 140. Thelight mask 138 is associated with the array of photodiodes 134 and has aplurality of openings therein, each opening corresponding to anindividual photodiode in the array 134. Similarly, light mask 140 isassociated with the array of photodetectors 136 and also has one openingfor each of the photodetectors. The light mask 138 is mounted on theprinted circuit board 130 beneath the array of photodiodes 134 along theopening in the printed circuit board 130. The light mask 138 is alignedwith the photodetectors 134 so that the openings in the light mask 138are directly beneath a corresponding photodiode in the array. The lightmask 138 minimizes the amount of light emitted by a photodiode that canbe detected by a photodetector other than the correspondingphotodetector. The light mask 140 is mounted on top of the photodetectorarray 136 so that the openings therein align with the individualphotodetectors. The light mask 140 further eliminates extraneous lightfrom the photodiodes as well as extraneous ambient light.

[0107] Also mounted on the printed circuit board 130 are a plurality oflight-emitting diodes 142, as shown in FIG. 7C in broken line. Thelight-emitting diodes are mounted on a side of the printed circuit boardopposite the side on which the photodiodes and photodetectors aremounted on. The light-emitting diodes 142 are mounted around theperimeter of the opening in the printed circuit board 130 and arereceived in a recessed portion 144 of the bezel 116. The light-emittingdiodes 142 comprise a means for providing visual feedback to a userinserting a card 120 into the bezel 116, as described further below. Inthe preferred embodiment, the light-emitting diodes 142 are duallight-emitting diodes capable of producing two primary colors and athird combination color.

[0108] Referring now to FIG. 6, an electrical schematic of the cardreader is shown. The schematic includes the array of photodiodes 134disposed along one side of the card reader opening 118 and the array ofphotodetectors 136 disposed along the opposite side of the opening 118.In the preferred embodiment, there are eight photodiodes and eightcorresponding photodetectors. The photodiodes are arranged in pairs,with the two photodiodes within each pair being connected in a serialfashion. The anode of the first photodiode in the pair is coupled to thesupply voltage through resistor, while the cathode of a secondphotodiode in the pair is connected to an output of a driver circuit144. The driver circuit, in the preferred embodiment, includes two opencollector inverters connected in parallel. A signal is provided to thedriver circuit 144 by the PT controller 98 over a conductor 146. Asignal on conductor 146 causes the driver circuit 144 to conduct currentand thereby actuate the photodiodes 134 substantially simultaneously.

[0109] The photodetectors 136 are comprised of a plurality oflight-sensitive phototransistors PD1-PD8. The emitters of thephototransistors PD1-PD8 are all coupled to ground. The collectors ofphototransistor PD1 and PD8 are connected together and to a conductor148 by which the PT controller 98 senses light detected by eitherphototransistor PD1 or PD8. Phototransistors PD2 and PD7 are similarlyconnected with the collectors of each being connected to a conductor150. The collectors of phototransistors PD3 and PD6 are also commonlyconnected to a conductor 152. The collectors of the centerphototransistors PD4 and PD5, however, are connected to separateconductors 156 and 154, respectively. Also connected to each of theconductors 148-156 is a corresponding pullup resistor. In the preferredembodiment, the pullup resistors are included in a resistor pack 158.Each of the conductors 148-156 are connected to a connector 170, whichis coupled to the PT controller 98 as described below.

[0110] Based on the above configuration of the phototransistors PD1 andPD8, only five conductors are required to sample all eight of thephototransistors. Without more information, however, the player trackingcontroller 98 would be unable to determine which of the twophototransistors commonly connected to a particular conductor, e.g.,conductor 148, detected light. For example, if either phototransistorPD1 or phototransistor PD8 detect light, the voltage level on conductor148 will drop from a high voltage of approximately 5 volts to a lowvoltage of approximately 0.7 volts. Without more information, the playertracking controller 98 would be unable to determine which of the twophototransistors, PD1 or PD8, actually sensed the light. According tothe invention, however, the card 120, as shown in FIG. 7A, includes afirst slot 150 by which the PT controller 98 can determine which of thetwo photodetectors detected the light, as described below.

[0111] The card 120 includes five rows of slots 152-160. The rows ofslots 152-160 are arranged in a matrix with the corresponding slotlocations within each of the rows being aligned in columns. Only thefirst slot 150 of row 152 cannot be aligned with any other slots, i.e.,slot 150 is in a column all by itself. The individual slots within therows of slots 152-160 encode unique player tracking information. Eachslot represents a single binary bit in the player tracking information.Either one of two conventions can be used to encode the information.First, a slot can represent a binary 1 and no slot can represent abinary 0. Second, a slot can represent a binary 0 and no slot canrepresent a binary 1. The player tracking information can include: aunique player identification number, the casino issuing the card, playermembership information, etc.

[0112] In the preferred embodiment, the card includes five rows of slotseach having a maximum number of nine individual slots, thereby producing45 possible slots. The first row of slots 152, however, is not used toencode player tracking information, but instead is used to synchronizethe sampling of the player tracking information by the player trackingcontroller 98. Thus, only 36 slots are used to encode player trackinginformation in the preferred embodiment. This still allows 2{circumflexover ( )}³⁶ possible combinations, which is more than adequate.

[0113] The PT controller 98 uses the first row 152 to synchronize thesampling as follows. The PT controller 98 continuously samples theoutputs of PD4 and PD5 looking for a slot. If a slot is detected oneither PD4 and PD5 and no other slots are detected by any otherphototransistors the PT controller 98 determines that the detected slotmust be slot 150. The PT controller 98 then continuously samples theoutput of the phototransistor that detected slot 150. Once a new slot isdetected by that phototransistor, the PT controller 98 then samples theoutputs of the other phototransistors, i.e., PD1-PD3 and PD6-PD8, onconductors 148, 150 and 152 for slots in of the other rows. Thus, the PTcontroller 98 synchronizes the sampling of the other rows of slots tothe detection of a slot in the first row 152.

[0114] It is important for the card reader to detect the orientation ofthe card in order to correctly interpret the player identificationinformation encoded on the card. The card reader detects the orientationof the card 120 by detecting the slot 150. If slot 150 is detected byphototransistor PD4, then the card reader knows that the card is in theorientation shown in FIG. 7A. In that case, the card reader knows thatthe player tracking information is actually being detected onphototransistors PD5-PD8, and can interpret the player trackinginformation accordingly. If, however, phototransistor PD5 detects slot150, then the card reader knows that the card 120 is oriented 180degrees from that shown in FIG. 7A. In that case, the card reader knowsthat the player tracking information is being detected byphototransistors PD1-PD4, and can interpret the information accordingly.The PT controller 98 can simply transpose the player trackinginformation sensed on conductors 148-152 depending upon the detectedorientation of the card. Thus, the card reader according to theinvention is able to correctly interpret the player tracking informationregardless of how the player inserts the card 120 into the bezel 116 ofthe card reader. The invention is able to accomplish this with only fiveconductors between the eight phototransistors PD1-PD8 and the PTcontroller 98.

[0115] The card reader further includes a plurality of light-emittingdiodes 142 that are mounted on the printed circuit board 130 andreceived in the recess 144 of the bezel 116, as shown in FIG. 7C. TheLEDs 142 are mounted on the-printed circuit board 130 so as to surroundthe card reader opening 118 as shown in FIG. 6. In the preferredembodiment, the card reader includes 24 dual diodes arranged in pairs.The dual diodes have two separate diodes, each being able to emit adifferent primary color of light. In the preferred embodiment, the dualdiodes emit either red or green light. The dual diodes can also emit athird combination color if the two individual diodes in the dual diodeare actuated simultaneously so that the two primary colors combine. Inthe preferred embodiment, this combination color is approximately orangedue to the differences in the intensities of the red and green light.

[0116] The dual diodes are essentially treated as two individual diodes.The red diodes R in the dual diodes are driven by a driver circuit 162,while the green diodes G in the dual diodes are driven by another drivercircuit 164. The driver circuits 162 and 164 are, in the preferredembodiment, two open collector drivers connected in parallel, as withdriver 145. However, other equivalent driver circuits would be apparentto those skilled in the art.

[0117] The dual diodes are arranged in pairs with the anodes of one ofthe dual diodes being coupled to the supply voltage +5V and the cathodesof the other dual diode being connected to the output of thecorresponding driver circuit. Accordingly, the red diodes are commonlydriven by driver circuit 162, which is responsive to a signal receivedfrom the PT controller 98 on conductor 166. Similarly, the green diodesare commonly driven by driver circuit 164, which is responsive to asignal received from the PT controller 98 on conductor 168. Therefore,the PT controller 98 can selectively actuate the red diodes, the greendiodes or both by generating the corresponding signals on conductors 166and 168.

[0118] All of the conductors over which the PT controller communicateswith the card reader, i.e., 146-156 and 166-168, are connected to aconnector 170 as shown in FIGS. 6 and 7A. The player tracking module 44then includes a cable 172 that is connected between the connector 170and the PT controller 98, as shown in FIG. 5.

[0119] Although the preferred embodiment of the card reader is anoptical card reader, the invention is not limited to such. The lightedbezel can be used in conjunction with any form of card reader such as amagnetic card reader, a bar code reader, etc. The method of providingvisual feedback to the player herein described is a general method whichcan be used with a plurality of cards and card readers.

[0120] 5. Display

[0121] Referring now to FIG. 8, a schematic for the display circuit 102of the player tracking module 44 is shown. The circuit 102 includes adisplay controller 174, which in the preferred embodiment is a partnumber HD6473258P10 manufactured by Hitachi of Tokyo, Japan. Coupled tothe display controller 174 is a memory 176 via bus 178. The memory 176,in the preferred embodiment, is a 32 KB SRAM. The memory 176 stores thevariables and parameters necessary for the controller 174 to communicatewith both the PT controller 98 and the display driver 186. The bus 178includes the necessary address lines, data lines and control lines tointerface in memory 176.

[0122] In the preferred embodiment, the display 102 includes a vacuumfluorescent display (VFD) 184, which is organized as a 16×192 displaymatrix. Such displays are well-known in the art of digital electronics.The VFD 184 is driven by a driver circuit 186, which includes aplurality of individual drivers serially interconnected. In thepreferred embodiment, these serial drivers are part number UCN5818EPF-1,manufactured by Allegro Microsystems, Inc. of Worcester, Mass. Thedriver circuit 186 is connected to the VFD 184 by bus 188, whichincludes 160 individual conductors. The manner in which the 160 buslines are connected between the driver circuit 186 and the VFD 184 isknown in the art, and is therefore not described in detail herein.

[0123] The display controller 174 interfaces with the driver circuit 186by a plurality of signal lines 190. These signal lines transmit thestandard driver interface signals to the driver circuit 186. Thesesignals include: a clock signal CLOCK, serial input data signal SDATA, aframe signal FRAME, a strobe signal STROBE, two output enable signalsOE1/and OE2/, a column clock signal COL CLOCK, and a column outputenable signal COL OE/. These signals have well known functions in thedisplay art and are therefor not discussed in detail. The signal nameshaving a “/” represent active low signals while all other signals areactive high. The display controller 174 generates these signals in therequired sequence in order to serially clock the reformatted displaydata to the driver circuit. One of ordinary skill in the art couldprogram the display controller 176 to generate these signals in order todisplay the desired message on the VFD 184 based on the foregoingdescription.

[0124] The display 102 also includes a serial interface 192. The serialinterface 192 is the means by which the PT controller 98 communicates aplayer tracking message to the display 102. In the preferred embodiment,the serial interface 192 includes two opto-isolator circuits: one forthe serial send data, the other for the serial transmission data. Thedisplay controller 174 is connected to the serial interface 192 over atwo conductor serial bus 194, one conductor for receiving serial datafrom the serial interface 192, the other for transmitting serial datathereto. A connector 196 is also coupled to the serial interface 192.The connector 196 includes four terminals. Two of the connectorterminals are dedicated to receiving serial input data and the other twoterminals are dedicated to transmitting serial data. A cable (not shown)couples the display 102 to the player tracking module 44 betweenconnectors 196 (FIG. 8) and connector 115 (FIG. 5).

[0125] 6. Discrete Input Section

[0126] The display 102 further includes a discrete input section 198.The discrete input section 198 is an interface between the discreteoutputs of a gaming device and the display controller 174 much in thesame way that the discrete machine interface 72 allows the datacommunication node to interface with a gaming device. Although in thepreferred embodiment the discrete input section is unconnected to anydiscrete machine inputs, the discrete input section 198 allows thedisplay 102 to operate as a stand-alone module for gaming devices incertain configurations. The discrete input section provides discreteinput signals from an external device to the display controller 174 overa bus 200. The discrete input section 198 includes opto-isolatorcircuits such as part number TLP620 manufactured by Toshiba Corporationof Tokyo, Japan which provide single-ended input signals to the displaycontroller 174.

[0127] D. Personality Board

[0128] Referring now to FIG. 9, a personality board 202 is shown inschematic form. The personality board 202 uniquely identifies the gamingdevice on the network. The personality board 202 indicates the type ofgaming device, e.g., slot machine or video poker, including themanufacturer, and provides a unique machine identification number thatthe host computer can use to uniquely address the gaming device. Thepersonality board 202 allows the devices to be readily removed andreinstalled in the network without any manual reconfiguration by theoperator, such as resetting dip switches.

[0129] The personality board 202 couples the data communication node 42to a gaming device. The personality board 202 includes two connectors204 and 206 and an identification circuit 208. The connector 204 couplesto the data communication node 42, as described further below. Theconnector 206 connects to the particular gaming device. The componentsshown in FIG. 9 are mounted on a printed circuit board that is mountedinside a connector harness (not shown). The personality board allows theDCN to be easily removed and reinstalled from the network with minimaleffort.

[0130] The personality board uniquely identifies the machine byproviding both a configuration number, which indicates the type ofgaming device that is connected to the connector 206 and a uniqueidentification number, which is used by the system 10 to maintainrecords on the machine. The configuration number includes a six bitbinary number which indicates the type of gaming device connected to thepersonality board 202. Each machine type is assigned a uniqueconfiguration number. This configuration number is encoded on linesCNFG0-CNFG5, which are connected to terminals 204Q-204V, respectively,of connector 204. Each line represents one bit of the binaryconfiguration number. The individual lines are either tied to a supplyvoltage to represent a binary one or to ground to represent a binaryzero. The six bit configuration number used in the preferred embodimentcan encode up to 2{circumflex over ( )}⁶ different combinations and,therefore, different machine types. The configuration number for theembodiment shown in FIG. 9 is equal to 3CH.

[0131] The configuration lines CNFG0-CNFG5 are coupled to the inputs ofparallel to serial converter 86 (FIG. 3) through a connector (notshown). The terminals 204Q-204V of connector 204 have correspondingterminals 85Q-85V of connector 85, as indicated by correspondinglettered suffixes. This same lettering convention is used throughout.

[0132] The configuration number is used by the DCN controller 46 as ameans of interpreting the discrete input signals received from themachine through connector 206. Individual conductors coupled betweenconnector 204 and 206 are labeled to correspond to the machine typehaving a configuration number 3CH. For a different machine type having adifferent configuration number, many of these conductors may havedifferent functions. By providing a unique configuration number, the DCNcontroller can interpret the signals received on these linesaccordingly.

[0133] The personality board 202 also includes an identification circuit208 which provides a unique machine identification number to the datacommunication node 42. The unique identification number is stored in anonvolatile memory 210 and provided to a terminal 204N on conductor ID.In the preferred embodiment, the nonvolatile memory 210 is a part numberDS2224 manufactured by Dallas Semiconductor of Dallas, Tex. In thepreferred embodiment, the nonvolatile memory 210 includes a 32 bit ROMhaving a factory-lasered unique serial number stored therein. Thisserial number, i.e., the machine identification number, can be read outof the memory 210 by the DCN controller 46 to uniquely identify themachine connected thereto. The protocol for reading the identificationnumber out of the memory 210, as is described in the data sheet for thepart, is well known in the art.

[0134] The identification circuit 208 includes a number of discretecomponents. The memory 210 has a zener diode 212 coupled across thepower and ground terminals of 213 and 215 thereof. The identificationcircuit 202 also includes a first diode 214 coupled between the powerterminal 213 and a data output terminal 217. The circuit 208 furtherincludes a second diode 216 coupled between the data output terminal 217and the ground terminals 215. A resistor 218 is interposed between thedata output terminal 217 and the connector terminal 204N. The terminal204N is coupled to a corresponding terminal 74N of connector 74 (FIG. 4)by a bus 220 (FIG. 2).

[0135] The discrete outputs from the machine, e.g., coin in, coin out,etc., are also supplied to the data communication node 42 via bus 220.The bus 220 connects connector 74 of the data communication node 42 andthe connector 204 of the personality board 202 such that terminalshaving corresponding lettered suffixes are connected. For example,terminal 74C of connector 74 is connected to terminal 204C of connector204 by a individual conductor within bus 220. All the other terminalsare similarly connected by the bus 220.

[0136] The network interface 49 of the data communication node 42 isalso coupled to the personality board by a bus 222, as shown in FIG. 2.Bus 222 includes four conductors which connects the four terminals ofconnector 51 with four corresponding terminals of connector 204, asindicated by the common lettered suffixes. It is over these four linesthat the DCN controller 46 indirectly communicates with the floorcontroller.

[0137] The serial machine interface 60 is also coupled to thepersonality board 202 by a bus 224, as shown in FIG. 2. The bus 224includes four conductors which couple four terminals 62DD and 62EE ofconnector 62 with corresponding terminals 204DD and 204EE, respectively.It is over these four conductors that the DCN controller 46 communicatesreconfiguration commands to the machine. The DCN controller transmitsdata through the terminal 204DD, which is provided to the machine onconductor MACHINE RX. The machine responds to the configuration commandon the conductor MACHINE TX. The use of these two conductors will becomemore apparent in the description of the operation hereinbelow.

[0138] Although buses 220, 222, 224 and 226 have been described asseparate buses, the individual conductors within these buses could, andare in the preferred embodiment, combined into a single bus that isconnected between the data collection node 42 and the personality board202. To connect the data collection node 42 and the personality board202 a connector (not shown) is mounted on the data collection node 42and a mating connector (not shown) is mounted on the personality board202. The two connectors are then mated together to connect the datacollection node 42 to the personality board 202. The personality boardis then coupled to the corresponding gaming device by a cable 225 (FIG.2).

[0139] E. Bonus Display Drivers

[0140] Referring now to FIGS. 10 and 11, two bonus display drivers areshown. The data communication node 42 is designed to support either ofthe display drivers. The data communication node 42 is coupled to thedisplay driver of FIG. 10 through connector 228. An opto coupler 230optically isolates the data communication node from a triac circuit 232which includes a triac 234. One terminal of the triac 234 is connectedto a terminal 236B of a connector 236. Another terminal of the triac 234is connected to a terminal 236C of connector 236. A bonus display suchas a light or sound generating means is coupled across terminals 236Band 236C so that the triac 234 could drive the external bonus displayresponsive to an actuation signal from the data communication node 42.

[0141] A second embodiment of the display driver is shown in FIG. 11. Inthis embodiment, the data communication node 42 is coupled to the drivercircuit through connector 238. The driver circuit of FIG. 11 includes arelay 240 operatively coupled to a transistor 242. The relay 240 is atwo-position relay which toggles between the two positions responsive toa current passing through transistor 242. The transistor 242 conducts acurrent responsive to an actuation signal received on terminal 238B fromthe data communication node 42.

[0142] The display drivers are used by the data communication node 42 toactivate a display on the gaming device which indicates that the machineis now in a bonus mode or condition.

[0143] F. Floor Controller

[0144] As shown in FIG. 1, the floor controller is directly connected toboth the high speed network 38 and a plurality of gaming devices. Thefloor controller is responsible for monitoring the activity of each ofthe gaming devices connected thereto and reporting this activity to thedatabase 32. In addition, the floor controller is responsible fortransmitting a reconfiguration command to a selected one or more of thegaming devices during certain bonus conditions. These conditions will bedescribed in detail in the operation section below.

[0145] The floor controller is connected to the associated gamingdevices by current loop networks. Because of the limitations of thecurrent loop network, only a predetermined number of gaming devices canbe supported on any one current loop network. In the preferredembodiment, each current loop network supports up to 64 gaming devices.In order for each floor controller to support more than thispredetermined number of gaming devices, each floor controller isequipped with a communication board 246, as shown in FIG. 12. Thecommunication board 246 supports up to 16 separate current loopnetworks. The board is a standard size card that fits into one of theISA card slots in the back of the floor controller. The board includes amale edge connector (not shown) which mates with a female back planeconnector (not shown) in the floor controller. The back plane connectorprovides the floor controller CPU data, address, and control lines tothe communication board 246 to enable the communication board and thefloor controller CPU to communicate.

[0146] The communication board 246 includes eight separatemicrocontrollers 248A-248H. The microcontrollers communicate with thefloor controller through ISA bus interface logic 247 over buses 249A and249B. The microcontrollers are shown in a daisy-chain connection in FIG.12, but any other equivalent interconnection scheme can be used. Thedata received from the floor controller microprocessor is passed betweenthe microcontrollers from 248A to 248H, as indicated by the arrows. Eachmicrocontroller is responsible for passing the data along anddetermining whether the data includes a message for a machine connectedto its corresponding current loop networks.

[0147] Each microcontroller is responsible for two current loopnetworks. Each microcontroller communicates with its associated gamingdevices via two corresponding current loop networks. Two serial signallines 251 connect each microcontroller to a current loop driver circuit250. The driver circuit 250 provides the necessary current drive tosupport the current loop network. Each pair of serial signal lines 251has a corresponding pair of current loop lines 253. The current loopdriver circuit 250 can either be located on the communication board asshown in FIG. 12 or on a separate printed circuit board (not shown). Iflocated on a separate board, the current loop driver circuit 250 can beconnected to the communication board by a cable.

[0148] In the preferred embodiment, the last microcontroller 248H issolely responsible for communicating with the floor controllermicroprocessor. All of the data received from the machines over thevarious current loop networks are passed along to the microcontroller248H by the associated microcontroller. The microcontroller 248Hanalyses the data and determines whether the data needs to becommunicated to the floor controller. If not, the last microcontrollerrecords the communication but does not forward the data to the floorcontroller. This helps off-load some of the floor controllercommunication processing to the communication board.

II. Operation

[0149] The above-described system allows a casino in which the system isinstalled to run promotions on any properly equipped gaming machineswhile simultaneously gathering player tracking and accounting data fromall machines. The system provides the capability for the casino toselect which of the plurality of machines are used in any givenpromotion. The system further allows any number of different promotionsto operate simultaneously.

[0150] Each promotion involves sending a reconfiguration command fromthe floor controller to a gaming device that has been selected to bepart of a given promotion over the associated network. Upon receipt ofthe reconfiguration command, the gaming device reconfigures its payoutschedule in accordance with the received reconfiguration command. Asdescribed above, reconfiguring a gaming device payout schedule, in thepreferred embodiment, includes activating a bonus payout schedule thatpays out bonus amounts in addition to the amount determined by thedevice payout table.

[0151] A partial list of the promotions according to the inventioninclude, but are not limited to: a multiple jackpot wherein the gamingdevice reconfigures its payout to be a multiple of its default payoutschedule; a bonus jackpot wherein the gaming device reconfigures itspayout schedule to payout an additional bonus amount when certainconditions are met; and a progressive jackpot wherein two or more gamingdevices are combined in a progressive jackpot having a progressivejackpot payout schedule. In addition to these, many other promotions arepossible by the above-described system for controlling and monitoring aplurality of gaming devices.

[0152] The system 10 also allows for improved player tracking. As withstandard player tracking, the above-described system monitors andreports how many coins are played by each player. The system 10,however, also includes the ability to record how long each player spendsat each machine and the number of coins won, games played, and handjackpots won by each player. All this information is stored on thedatabase, which can be later analyzed for future targeted direct mailingcampaigns. The player tracking according to the invention also allowsthe casino to schedule buses and other groups and measure theirprofitability. The system also allows for cashless play as well asadvanced accounting and security features.

[0153] Another feature of the above-described system is jackpotannouncements. The jackpot announcement feature displays a message on areader board or display located in the casino which announces a jackpotas soon as a jackpot is won, i.e., as soon as the reels stop spinning.The floor controller generates the jackpot announcement once a DCNconnected thereto indicates a jackpot is won. An example of such amessage might be: “Now paying on machine 1342, a jackpot of $300.” Withprior art data collection systems, the amount of the jackpot is onlyknown after the payment is made. Even then the system must account forpartial pays, hopper empty, etc.

[0154] An advantage of the current system over prior art systems is theability to implement better tournament systems. In a slot tournament,players pay a fee to play. All play during the session is free. Theplayers accumulate credits instead of cash. The person with the mostcredits at the end of the tournament wins. Games are usually manuallyaltered to provide payouts of 200 to 300% to make the games more fun.The games are altered manually by replacing the read only memory (ROM)in the gaming devices.

[0155] One exciting aspect of tournament play is to see who is ahead. Nocurrent system can display this information in real time. This isbecause current systems can only measure winnings as they are added tothe credit meter or paid from the hopper (some casinos use tournamenttokens instead). Since credits are usually added at a rate of 10 persecond, a 1,000 credit win can take 100 seconds to register. Casinosattempting to create display boards showing who is ahead are frustratedby the lag time. The jackpot announcement of the invention allowscasinos to display the player with the most credits by comparing thenumber of credits for each player. This comparison and display isperformed real time as each transaction is completed.

[0156] In order to implement each of these features, the variouscomputers and microcontrollers each execute software or firmware. Thissoftware and firmware routines are described below. These routines aredescribed with reference to accompanying flow charts. These flow chartswould enable one of ordinary skill in the art of computer programming towrite a corresponding computer program which the computer ormicrocontroller could execute.

[0157] A. Data Communication Node

[0158] 1. Power Up Procedure

[0159] Referring now to FIG. 13, a power up procedure 252 for the datacommunication node is shown. This procedure is executed by the DCNcontroller 46 when initially powered up. The first step of the procedureis to validate the RAM to ensure that it is not corrupted and to set upall the DCN hardware. Validating the RAM involves writing known patternsof 1s and 0s to the DCN RAM. This RAM can either be internal to the DCNcontroller 42 or external as shown in FIG. 2. Setting up the DCNhardware includes initializing timers and interrupts.

[0160] Next the DCN controller checks the RAM in step 255 by reading thepattern of 1s and 0s back out of the RAM to ensure that the RAM is fullyfunctional. If the RAM turns out to be defective the DCN controller goesinto an endless loop in 256.

[0161] 2. Reading Unique Identification Number

[0162] If the RAM is fully functional, the DCN then reads the uniqueidentification number from the personality board. As described above,this unique identification number is stored in a nonvolatile memory 210on the personality board. Reading the unique ID number out of thenonvolatile memory involves following the memory manufacturer'sinterface protocol as specified in the nonvolatile memory data sheet.The unique identification number provides a means for uniquelyidentifying the gaming device.

[0163] After the unique ID has been read from the personality board, theDCN processes the discrete machine inputs in step 260. This step will bedescribed in further detail in Subsection 3, Monitoring Gaming DeviceDiscrete Input below. After the discrete inputs have been processed instep 260, the DCN processes the machine serial interface in step 262.This step is described further below in Subsection 4, Processing GamingDevice Serial Interface. Next, the DCN processes the network interface,i.e., the interface between the DCN and the floor controller connectedthereto. The process network interface step 264 is described furtherbelow in Subsection 5, Processing Network Interface. Finally, the DCNprocesses the player tracking interface in step 266. This step isdescribed below in Subsection 6, Processing Card Insertion. At thecompletion of step 266 the DCN loops back to step 260 and continuously,sequentially executes steps 260-266.

[0164] 3. Monitoring Gaming Device Discrete Input

[0165] Referring now to FIG. 14, the DCN step of monitoring the gamingdevice discrete inputs 260 will now be described. The DCN first readsthe discrete inputs on input lines 76 in step 267. One particular set ofdiscrete inputs is shown in FIGS. 4 and 9 for a particular gamingdevice. The actual discrete inputs present will depend on the machinetype, as indicated by the configuration number, which is also read bythe DCN controller 46. Most gaming devices provide at least some of thefollowing discrete inputs: coins in, coins out, coins to drop, gamesplayed, attendant paid jackpots, slot door, drop door, progressivejackpots, and bill validators. The system supports all of these discreteinputs as well as others.

[0166] The DCN keeps track of the machine activity by maintainingseveral meters in memory. Each meter, in the preferred embodiment,includes six digits. Moreover, to improve the reliability of the system,the DCN maintains redundant backup copies of these meters with an orderto replace the original meters in the event that the originals arecorrupted. In step 268, the DCN increments the meters as required basedon the discrete inputs. The meters are maintained even in the event thatthe DCN is disconnected from the floor controller. Once the DCN isreconnected to the floor controller, all the activity level informationis then available. Step 268 will be discussed further below.

[0167] Next, the DCN processes the drop door signal in step 270. Thedrop door signal DROP DOOR indicates that the drop door on the machinehas been opened. This is an important event and is therefore processedseparately.

[0168] In step 272, the DCN validates the meter values to determinewhether the values stored in the meters are valid. The DCN checkswhether the meter values are valid in step 274. In the preferredembodiment, a check sum is maintained for each meter value. Thus, theDCN in step 274 checks to see whether the check sum is correct based onthe current meter value. If the meter values are okay, the discreteinput monitoring step 260 is complete. If the meter values are notvalid, the DCN replaces the meter values with the redundant back copy ofthe meter values in step 278, and then the step 260 is complete.

[0169] Referring now to FIG. 15, increment meter step 268 is shown infurther detail. The sequence shown in FIG. 15 is repeated for each metervalue that has changed. The first step is to adjust the meter valuebased on the discrete inputs and to calculate the associated check sum.Next, the DCN determines whether the particular meter has an activeassociated countdown count in step 282. Some games or promotionalactivities require the player to reach a certain level of activity inorder to be eligible for certain bonus points. These countdown countsare used to determine whether the player has achieved this level ofactivity. For example, the player may be required to play a certainnumber of coins before being awarded any points. If the countdown countis active, the DCN adjusts the current players count down values in step284 based on the corresponding adjustment of the associated meter.

[0170] In step 286, the DCN sets the current message to the count downmessage. The count down message indicates to the player when he or shewill be eligible for the bonus points. Finally, in step 288 the DCN setsthe current bezel color and rate to a count down color and rate. Thiscolor and rate information is subsequently transmitted to the playertracking node for processing, as described further below. The countdowncolor indicates the bezel color and the count down rate indicates thatflashing rate of the bezel color displayed during the count downmessage.

[0171] 4. Processing Gaming Device Serial Interface

[0172] Referring now to FIG. 16, a process 262 for processing the gamingdevice serial interface is shown. The serial machine interface 60, asshown in FIG. 2, allows the DCN controller 46 to communicate with thegaming device through the personality board. This serial machineinterface allows the DCN controller 46 to transmit reconfigurationcommands to the gaming device in order to reconfigure the payoutschedule of the machine in accordance with the reconfiguration command.In addition, the serial machine interface provides an additional meansfor determining the activity level of the gaming device. Instead ofreading the discrete machine inputs, the DCN controller 46 can transmita status request command to the machine over the serial interface andthe machine can respond back with the requested status information.

[0173] Any communication protocol can be used to implement thiscommunication path over the serial machine interface, as is known in theart. An example of one such protocol uses a data packet including acommand code, a message sequence number, a CRC, and a variable lengthmessage. In the preferred embodiment, either the DCN controller 46 orthe machine can initiate communications over the serial machineinterface. However, if the machine detects that the DCN is trying tosend a message to the machine, the machine must abort its message andattempt to resend the message at a later time.

[0174] The preferred embodiment of the system supports many differentreconfiguration commands. A partial list of the reconfiguration commandsis given below in Table 1. These reconfiguration commands are sent fromthe DCN controller 46 to the machine over the serial machine interfacewherein the machine reconfigures its payout schedule in accordance withthe particular reconfiguration command. The reconfiguration commands donot originate with the DCN, instead the reconfiguration commandsoriginate from the floor controller and are transmitted to a particularmachine over the associated current loop network or the command canoriginate at one of the other computers on the high speed network. TheDCN is simply responsible for forwarding the reconfiguration commandonto the gaming device on receipt of the reconfiguration command overthe associated current loop network coupled between the floor controllerand the DCN. TABLE 1 Examples of Reconfiguration Commands 1. Bonus PayFrom Hopper (Coin Format) 2. Bonus Pay to Credit Meter (Coin Format) 3.Bonus Pay from Hopper (Dollar Format) 4. Bonus Pay To Credit Meter(Dollar Format) 5. Add Non-cash outable credits to Game 6. Begin DoubleJackpot Time 7. Stop Double Jackpot Time

[0175] The actual process of processing the machine serial interfacebegins in step 292 wherein the DCN polls the machine to determine itslevel of activity. This polling step includes sending a status messagefrom the DCN to the machine over the serial machine interface. Inresponse, the machine will send a packet of status informationindicating the current amount of activity on the machine. The statusinformation included in the response will depend on the type of machinethat the DCN is communication with.

[0176] The data communication node 42, in step 294, waits for a reply tothe status request. If a reply is received, the DCN indicates that themachine is “on line” in step 296 and processes the machine reply in 298.The step of processing the machine reply includes updating the metervalues, as done when processing the discrete inputs. After the machinereply has been processed, the process 262 is complete.

[0177] If the DCN does not receive a reply from the machine in step 294,the DCN indicates that the machine is “off line”. The DCN will wait fora predetermined amount of time before deciding that the reply is notreceived. In the preferred embodiment, this predetermined period isapproximately 110 milliseconds.

[0178] 5. Processing Network Interface

[0179] Another step in the DCN power up procedure 252 is the step ofprocessing the network interface 264. This step is described withreference to FIGS. 17-19. The network interface refers to the currentloop that connects the particular DCN with the associated floorcontroller. The following description assumes that the DCN has receiveda valid message from the associated floor controller. Because there aremultiple DCNs connected to any one current loop, the floor controllermust include some means for addressing a particular machine.

[0180] Although each machine includes a unique identification numberwhich could be used as the actual address for each DCN on the currentloop, it is unnecessary to use the unique identification as the actualaddress because there are only a limited number of DCNs connected toeach current loop. Accordingly, in the preferred embodiment of theinvention, the floor controller uses a shorthand token representation ofthe DCN's unique identification number to address the DCN. In thepreferred embodiment, a single byte address is used to address a DCN onany given current loop. This one-byte address allows up to 256 DCNs tobe supported on any given current loop network. In the preferredembodiment, however, only 64 such DCNs are connected to a single currentloop and therefore the single byte address is more than adequate. Thesingle byte address substantially reduces the amount of traffic on thecurrent loop network by reducing the number of bytes from four in theunique identification number to one for the shorthand tokenrepresentation.

[0181] The floor controller is responsible for generating the uniquesingle byte address for each data communication node on a given currentloop network. The process of assigning unique single byte addresses tothe DCNs is described below in Section C.

[0182] Once all the DCNs have been assigned a unique address, the DCNcan begin monitoring the current loop network for messages addressed toit. If the DCN detects a message addressed to it, the DCN executes step264. The DCN first checks to see whether the message is valid in step304. This check is done by computing the CRC value of the message andcomparing it to the CRC included with the message. If the two CRCsmatch, the message is valid and the DCN processes the network message instep 306. Processing the network message is described further below withreference to FIGS. 18 and 19. Once the message has been processed, theDCN sends a reply back to the floor controller over the current loopnetwork in step 308. The actual substance of the reply will depend onthe message received in step 306. If the message is invalid, the DCNdoes not reply.

[0183] Referring now to FIG. 18, the first step of processing thenetwork message is to determine what type of message was sent from thefloor controller in step 312. There are three basic types of messagesthat the floor controller sends to the DCN. The first is a request fordata from the DCN. If this type of message is detected the DCN buildsthe data requested and transmits the data in a reply message. The mainuse of this message type is to gather status and meter information fromthe DCN.

[0184] Another type of message is one including configuration data forthe DCN. This message allows the floor controller to implicitly set theDCN's memory to a fixed value. This message is used to override theDCN's internal variables, e.g., to get a DCN out of a lock-up condition,or to download new firmware to the DCN for execution. On receiving thistype of message, the DCN simply overwrites its memory with theconfiguration data included in the configuration message in step 316.The DCN then builds an appropriate acknowledgment and transmits thisacknowledgment message to the floor controller in step 320.

[0185] The other type of message is one sent in response to a DCNrequest. The DCN processes this data in step 318, which is describedfurther in FIG. 19. If the message includes either the configurationdata or the data in response to a DCN request, the DCN builds anacknowledge message in step 320 and transmits this message to the floorcontroller.

[0186] The step of processing a floor controller message sent inresponse to a DCN request will now be described with reference to FIG.19. The first step of processing this type of message is for the DCN todetermine what type of data is included in the message. Once again thereare three types of data that can be included in this message type: areconfiguration command, card data, or other minor data. The DCN makesthis determination in step 324 by analyzing one of the bytes in the datapacket of the message. This byte will be referred to herein as thecommand byte. If the command byte indicates that the message containsreconfiguration data, i.e., the command byte equals a reconfigurationcommand, the DCN stores the reconfiguration data in a predefined datastructure in memory. Listed below in Table 2 is an example of a datastructure for storing the reconfiguration data. TABLE 2 ReconfigurationData Structure 1. Bonus Type 2. Mystery Jackpot Data: A. Number of coinsto award B. Number of seconds to award C. Pay award to 3. Bonus TimeData A. Jackpot Multiplier B. Jackpot Payout Limitations C. Number ofSeconds to Keep Bonus Time Active D. Minimum Activity Level

[0187] The bonus type field of the data structure indicates the type ofbonus state the machine is to be placed in. Examples of potential bonusmodes include progressive/nonprogressive, multiple jackpot, or mysteryjackpot. If the mystery jackpot is indicated, the mystery jackpot dataincluded in the structure specifies the conditions under which themystery jackpot is paid out. The mystery jackpot can be set to payout,e.g., after a certain number of coins in, handle pulls, which isspecified by subfields of the mystery jackpot data.

[0188] The bonus time jackpot is a promotion wherein the machine paysout more than that dictated by its default payout schedule. In oneembodiment of the bonus time promotion, the payout schedule of themachine can be modified to be a multiple of its default to payoutschedule, as specified in subfield (A) of the bonus time data. Thispromotion can be used to encourage gaming activity during off-peakhours, e.g., midnight to 4 a.m. on weeknights. Alternatively, the bonustime promotion can be activated on a random basis. The timing of themultiple jackpot is specified by the casino on one of the computersconnected to the network. The bonus time data also specifies theconditions under which the player becomes eligible for the bonus timejackpot. The subfield (B) of the bonus time data specifies whether theplayer is eligible for the bonus time data only if the player is playingthe maximum coin in the machine. Subfield (C) limits the bonus timepromotion to a predetermined number of seconds. This field limits thebonus time promotion to a predetermined number of seconds; if the playerdoes not hit a jackpot within this specified time period, the bonus timepromotion concludes. The minimum activity level can also be specified insubfield (D). This field can be used to specify the minimum activitylevel required by the player in order to be eligible for the bonus timejackpot. For example, the player can be required to play at least 20coins over the last three minutes in order to be eligible for the bonustime jackpot. An indicator light on the player's machine can be used toindicate when the player reaches the minimum activity level and therebybecomes eligible for the bonus time jackpot.

[0189] In another embodiment of the bonus time promotion, a bonus amountis awarded in addition to the payout according to the default of thepayout schedule of the machine. The amount of the bonus jackpot isspecified in subfield (E) of the bonus time data. For example, thisbonus time promotion might include five bonus amounts of $10, $25, $50,$100 and $500, which is specified by subfield (E). When a player hits aparticular jackpot, whichever bonus amount is specified by the bonusamount subfield this amount is automatically paid out in addition to thepayout amount determined by the machine's default payout schedule. Thisbonus time promotion can also be used in combination with subfields (C)and (D) to specify the conditions under which the player is eligible forthis bonus time jackpot award.

[0190] After the DCN has stored the reconfiguration data in step 326,the DCN will then send the appropriate reconfiguration command to themachine over the serial machine interface in step 328. The machine,responsive to the received reconfiguration command, reconfigures itspayout schedule in accordance with the received reconfiguration command.For example, if the reconfiguration command specifies a multiple jackpotcondition, the machine will reconfigure its payout to be a multiple ofits default payout schedule. The machine will reconfigure its payoutschedule in a similar manner for the other bonus types.

[0191] The other type of data that can be included in a response from aDCN request is card data or player tracking data. This data is sent tothe DCN in response to a status message from the DCN to the floorcontroller wherein the status message indicates that a player card hasbeen inserted. Included in this message is the card ID number detectedby the card reader. In response to this status message the floorcontroller will transmit a card insertion message to the DCN. The cardinsertion message includes information associated with the particularplayer ID number. An exemplary card insertion message data packet islisted below in Table 3. TABLE 3 Card Insertion Message Data Packet 1.Card Identification Number 2. Player First Name 3. Player Last Name 4.Current Point Balance 5. Casino Code

[0192] Upon receipt of the card insertion message, the DCN stores theplayer's name and points in order for this information to be displayedon the VFD display associated with the player tracking node. Then, a DCNsets the current message to a data received message in step 334.Finally, a DCN sets the current bezel color and bezel rate to a datareceived bezel color and bezel rate in step 336. The bezel colorspecifies the bezel color to be displayed by the card reader and thebezel rate specifies the flashing rate of the card reader LEDs. Thisbezel information is subsequently transmitted to the player trackingnode for processing thereby.

[0193] The final data type that can be included in the message sent fromthe floor controller in response to a DCN request is genericallyclassified as other minor data. This data includes general system or DCNspecific information such as display information.

[0194] 6. Processing Player Tracking Interface

[0195] The next step in the DCN process is processing of the playertracking interface 266. The DCN maintains a variable that indicates whatmessage is to be sent to the player tracking node. This variable isreferred to as the current message variable. Before transmitting amessage to the player tracking node, the DCN first checks this variableto see which of a plurality of messages should be sent to the playertracking node.

[0196] The process 266 begins in 340 by sending the current message tothe player tracking node that is specified by the current messagevariable. In addition to the current message, the DCN sends the bezelcolor and bezel rate information to the player tracking node. The bezelcolor and bezel rate information could have been specified by the floorcontroller or by the DCN itself.

[0197] Next, the DCN determines the card status in step 342. If there isno card inserted in the card reader, the DCN sets the current messagevariable to an attract message. This message specifies that the playertracking node is to display a message which will attract players to themachine. Similarly, the DCN sets the current bezel color and bezel rateto an attract bezel color and rate in step 346. This attract color andrate is part of the attract message that will be sent to the playertracking node when the current message is sent.

[0198] If the DCN determines that a good card has been inserted in thecard reader, the DCN processes the valid card in step 350. This step isdescribed further below with reference to FIG. 21.

[0199] If, however, the card status indicates that a bad card has beeninserted, i.e., an invalid card number, the DCN sets the current messagevariable to specify a card error message in 352 and the DCN sets thecurrent bezel color and bezel rate to a card error color and rate in354. This card error information is included with the card error messagethat is sent to the player tracking node when the current message issent.

[0200] 7. Processing Card Insertion

[0201] Referring now to FIG. 21, the process 350 for processing a validcard insertion is shown. The first step that the DCN executes is todetermine whether the card data corresponding to the valid card has beenreceived from the floor controller in step 356. If not, the DCN builds anetwork request message for the player name and points associated withthe card ID number in step 358. Next, the DCN sets the current messagevariable to specify a card inserted message is to be transmitted in step360. Finally, the DCN sets the current bezel color and rate to a cardinserted color and rate, which indicates to the player that the systemis still processing the card number. This information is sent to theplayer tracking node when the current message is sent.

[0202] If the card data has been received from the floor controller, theDCN then determines in step 366 whether player tracking has started forthe particular player. If player tracking has not yet started, the DCNsets the current message variable to the data received message in step368 and sets the current bezel color and rate to data received color andrate in step 370. If player tracking has started, the DCN processes theplayer tracking in step 372, as described with reference to FIG. 22.

[0203] Processing player tracking 372 begins with the step ofdetermining whether the player has received new points in 374. Thesepoints can be considered roughly as the equivalent of “frequent flyermiles” used by airlines. These points allow the system to runpromotionals whereby individuals are given points or credit associatedwith their card that can be redeemed toward the purchase of goods orservices offered by the casino. Typically these points are redeemed at aredemption counter in the casino for meals or clothing, for example. Thepoints, therefore, are an additional inducement to encourage play.

[0204] The player tracking system of the invention allows the casino todetermine how and when the player is issued points. The casino canspecify the type and number of coins that must be played before a playeris awarded a given number of points. The system uses this specifiedinformation to inform the player of his or her progress towardsreceiving additional points. The system encourages play by informing theplayer of how many additional coins must be played before receivingadditional points. For example, a player who is only one coin away fromreceiving points, but who desires to stop playing, may decide to play“one last coin” in order to receive the points. The system informs theplayer by displaying a message on the vacuum florescent displayindicating how many coins the player is away from receiving additionalpoints.

[0205] Referring now to FIG. 22, player tracking 372 begins with thestep of determining whether the player has received new points in 374.If no new points have been received, the DCN sets the current messagevariable to specify a countdown message in step 376 and sets the currentbezel color and bezel rate to a countdown bezel color and rate in step378. The countdown bezel color and rate indicates the player's progresstowards being awarded additional points.

[0206] If new points have been received, such as where the player hasplayed a given number of coins, the DCN sets the current messagevariable to a points won message in step 382 and sets the current bezelcolor and rate to a points won color and rate in step 384. The pointswon message informs the player of the number of points won.

[0207] The above-described tracking process provides a means forproviding visual feedback to the player inserting the card into the cardreader. By modifying the bezel color and bezel rate, the datacommunication node provides immediate feedback to the player concerningthe proper insertion of the card. If the player inserts-the cardproperly into the card reader so that the card reader senses a validuser identification number, the card reader provides positive visualfeedback to the user by illuminating the bezel. On the other hand, ifthe user improperly inserts the card so that the card reader cannot readthe user identification number, the card reader can provide negativevisual feedback to the player by illuminating the bezel with a differentcolor and/or flashing rate. In the preferred embodiment, this positivevisual feedback includes flashing the green LEDs to produce a flashinggreen signal around the card reader opening. The negative visualfeedback includes flashing the red LEDs. A third combination color isused during the processing of the player tracking information. Thisprocess provides immediate feedback to the player concerning theinsertion of the card in the card reader.

[0208] B. Player Tracking Module

[0209] The system described above allows for improved player tracking byrecording each and every machine transaction including: time of play,machine number, duration of play, coins in, coins out, hand paidjackpots and games played. The player tracking is conducted over thesame network as the accounting data is extracted. This allows theinvention to provide bonusing to certain individual players as well asduring certain times. As with standard player tracking, theabove-described system monitors and reports how many coins are played byeach player. The system according to the invention, however, alsoincludes the ability to record how long each player spends at eachmachine and the number of coins won, games played, and hand jackpots wonby each player. The system is able to record all this informationbecause the it operates on a transaction by transaction basis. Eachtransaction, whether it be a coin in, a handle pull, etc., is recordedby the system. Other prior art systems simply compile the playertracking information at the completion of play.

[0210] All the transaction information is stored on the database, whichcan be later analyzed for future targeted direct mailing campaigns. Theplayer tracking according to the invention allows the casino to schedulebuses and other groups and measure their profitability. Because thesystem records each transaction, the casino can reconfigure theircasinos to better match the tastes and demands of their customers.

[0211] The improved player tracking according to the invention alsoallows the casino to calculate theoretical wins exactly because thesystem always includes the most current information. The operation ofthe player tracking procedure is described below.

[0212] 1. Power Up Procedure

[0213] The operation of the player tracking module will now be describedwith reference to FIG. 23 where the powerup process 400 for the playertracking node is shown. As in the data communication node, the playertracking node first validates the RAM and sets up its associatedhardware in step 402. Next, the player tracking node tests the RAM instep 404 to determine whether the RAM is functioning properly. If not,the player tracking node, i.e., player tracking controller, terminatesits program in an error condition in step 406. If the player trackingRAM is fully functional, the player tracking node sequentially executessteps 408-414. In step 408 the player tracking controller processes theDCN interface between the player tracking controller and the DCNcontroller. In step 410 the player tracking controller updates theplayer tracking display. In step 412 the player tracking controllerupdates the bezel. Finally, the player tracking controller processes thecard reader in step 414. Each of these steps will now be describedfurther below.

[0214] 2. Processing DCN Interface

[0215] Referring now to FIG. 24, the steps for processing the DCNinterface are shown. First, the player tracking controller checks for anew message received from the DCN in step 416. If a new message has beenreceived, the player tracking controller overwrites its current messagebuffer with the new message and updates the bezel color and rate valueswith those contained in the new current message. Then, the playertracking controller builds a card status reply message in step 420. Thecard status message indicates whether a card has been inserted and if sowhether the card was a good card or a bad card, i.e., the card was readproperly by the card reader. If a valid card, the card status replymessage also includes the identification number encoded on the card.This step might also involve transposing the number encoded on the carddepending on the orientation in which the card was inserted into thecard reader. This card status reply message in then sent to the DCN instep 422.

[0216] 3. Processing Display Update

[0217] The process of updating the player tracking display is shown inFIG. 25 at 410. This process begins with the player tracking controllerscanning the display message for display attribute information. Examplesof such display attribute information is given below in Table 4. Eachdisplay attribute specifies a different graphic mode for the playertracking display. TABLE 4 DISPLAY ATTRIBUTE INFORMATION  1. Flash Rate 2. Center Display  3. Set Display Intensity  4. Use Small Lower Font 5. Use Small Upper Font  6. Use Normal Large Font  7. Set Pause Time 8. Set Scroll Speed  9. Center and Melt 10. Center and Scroll Down 11.Center and Scroll Up 12. Scroll Down and Stop 13. Scroll UP and Stop 14.Scroll Left and Stop and End of Message 15. Scroll Down 16. Scroll Up17. Scroll Right 18. Scroll Left 19. Reverse Video 20. Normal

[0218] The player tracking controller then determines whether any suchattribute information is found in the display message. If so, the playertracking controller sets up the display driver to incorporate thegraphics mode specified by the attribute information. The playertracking controller then strips out any display attribute informationfrom the display message in step 432 because the display attributeinformation is embedded in the display message. The remaining data inthe display message is the actual text to be displayed by the playertracking display, e.g., the player's name. The player trackingcontroller then sends this text to the display in step 434, which isthen displayed by the player tracking display.

[0219] 4. Processing Bezel Update

[0220] The player tracking node is also responsible for updating thebezel, both in terms of its color and flashing rate. This process 412 isshown in FIG. 26. The first step in processing the bezel update is todetermine to bezel color as specified by the DCN and then drive theappropriate LEDs in the card reader. As described above, the preferredembodiment of the card reader includes dual diodes having two primarycolored diodes that can be driven separately or in combination toproduce three different colors.

[0221] Next, the process determines the bezel rate as specified by theDCN. In a first case, the bezel rate is zero or off and thus the playertracking controller turns the LEDs off in step 442 in this case. If thebezel rate specifies a flashing rate, the player tracking controllerflashes the bezel at the appropriate bezel rate in step 442. Flashingthe bezel involves turning the LEDs on and off at the specified rate.This can be accomplished by a timer interrupt or a timing loop executedby the player tracking controller. The final option is that the rate canbe infinite or effectively a solid bezel color. In this case, the playertracking controller simply leaves the card reader LEDs on in step 446.This completes the processing bezel update process 412.

[0222] 5. Processing Card Reader

[0223] The next process step for the player tracking node is to processthe card reader. This process 414 is shown in FIG. 27. The first step isfor the player tracking controller to determine the card status in 450.In the preferred embodiment, the card status is determined by comparingthe checksum of the card, as read off the card by the card reader, to acomputed checksum of the data read off the card. Other methods ofdetermining card status can be used as well depending on the type ofcard reader employed.

[0224] If the player tracking controller determines that a valid cardwas inserted in the card reader, the player tracking controller sets acard status variable equal to good card. This card status is thensubsequently transmitted to the DCN controller. Then, the playertracking controller sets a card ID variable equal to the identificationnumber read by the card reader in step 454. The card status and the cardID provide the DCN with sufficient information to instigate the playertracking.

[0225] If, on the other hand, the card reader indicates that the cardwas read improperly or that the card is an invalid card for the cardreader, the player tracking controller sets the card status variable tobad card in step 458 and the card ID variable is cleared in step 460. Ifneither a valid or invalid card condition was detected in 450, theplayer tracking controller sets the card status variable to no card instep 462 and clears out the card ID in 460.

[0226] C. Floor Controller

[0227] 1. Power Up Procedure

[0228] Referring now to FIGS. 28-32, the process 464 operable on thefloor controller will now be described. The process 464 is shown inFIGS. 28-32 in flow chart forms. These flow charts would enable one ofordinary skill in the art to implement the process in computer softwareusing an appropriate computer programming language.

[0229] The floor controller process 464 begins at step 466 by openingthe database tables in the file server. As described above, the fileserver includes a commercially-available database program which storesthe machine activity information as well as player tracking informationand associated system characteristic parameters. This step 466 can alsoinclude fetching some or all of these system characteristics in order totrigger certain events such as bonus jackpots, as described below.

[0230] In step 468, the floor controller terminates any active playertracking sessions in the database. Because player tracking may have beenin progress when the floor controller became inoperable, when the floorcontroller powers up or becomes operable, there may be player trackingsessions initially active. In this step, the floor controller terminatesany such active player tracking sessions in order to place the databasein an initial state.

[0231] Another step that the floor controller executes after becomingoperable is to place an initial machine search message in an outputmessage queue 470. This search message is used by the floor controllerto determine which machines are connected to the floor controller. Thisoutput message is subsequently transmitted to all of the machinescoupled to the floor controller using a global message format, asdescribed below with reference to FIG. 31. In the preferred embodimentof the invention, the message handling is through the use of messagequeues. Furthermore, the preferred embodiment is both an output queuefor outgoing messages from the floor controller to the machines and aninput message queue for messages coming from the machines to the floorcontroller. Queues are well-known data structures in the art of computerscience and are therefore not further discussed herein. Alternatively,the message-handling could be done without the use of the queues. Insuch an embodiment the outgoing messages would be sent immediatelyrather than being queued, and any incoming messages would be processedimmediately.

[0232] The bulk of the work performed by the file server process 464 isperformed in message processing step 472. In this step, the floorcontroller processes all messages sent to or received from the machinesconnected thereto. This step will be described further below withreferences to FIGS. 29 through 31.

[0233] The process 464 also includes a system monitoring step 474. Thissystem monitoring step 474 administers certain system-wide events. Thesesystem-wide events include the counting-related events and bonusingevents. The floor controller continuously checks to see whether any ofthese events have been triggered. If any event has been triggered, suchas a bonusing event, the floor controller takes the appropriate actionto handle the event. The event may be triggered by the time and day orby user intervention or other event. The system monitoring step 474 willbe described further below with reference to FIGS. 32 and 33.

[0234] The final step in process 464 is for the floor controller tocheck for a termination condition in step 476. In the preferredembodiment, the floor controller checks to determine whether an ESCapekey as pressed. If an ESC key was pressed, the floor controllerterminates the process 464. If no ESC key was pressed, the floorcontroller loops back to step 472 wherein the message-processing stepand the system monitoring step are repeated. The floor controllercontinues in the loop 472-476 until the termination condition is sensed.

[0235] 2. Message Processing

[0236] As described above, the floor controller acts as a gatewaybetween the machines connected thereto and the file server, as shown inFIG. 1. The floor controller is responsible for forwarding the machineactivity received from the various machines to the database. The floorcontroller accomplishes this communication through the use of messages.The message processing step 472 is shown in more detail in FIG. 29.

[0237] The first step in processing the messages is for the floorcontroller to send any messages that are queued-up in the output messagequeue to the appropriate data communication node in step 480. Asdescribed above, the output message queue is a simple data structurethat is used to store any pending messages. Included in the message is adestination address by which the floor controller can determine which ofthe plurality of data communication nodes to send the message to. Nextthe floor controller receives any incoming messages from the datacommunication nodes coupled to the floor controller in step 482. Once anincoming message has been received, the floor controller parses throughthe message data included in the incoming message in steps 484 through486. In the preferred embodiment, the floor controller parses throughthe message data one byte at a time. Thus, in step 484 the floorcontroller reads the next byte in the incoming message, and in step 486the floor controller checks to see whether this is the last byte in themessage. In the preferred embodiment, the message includes a messagelength field which indicates the number of data bytes included in themessage. In this case, a floor controller in step 486 checks to seewhether the number of bytes read in step 484 is equal to the number ofbytes specified by the message length field.

[0238] Once the input message data has been parsed out of the incomingmessage, the floor controller takes the appropriate match in response tothe message data in step 488. This step is described further below withreference to FIGS. 30 and 31. Following the message-handling step 488,the floor controller checks in step 490 to determine whether anyresponse is pending. The floor controller makes this determination bychecking a transactions-in-progress structure which indicates whetherthe floor controller needs to respond to any previous message. If aresponse is pending, the floor controller queues up an appropriateoutgoing message in the output message queue in step 492. Otherwise, thefloor controller completes the message processing step 472.

[0239] Referring now to FIG. 30, the message-handling step 488 is shownin more detail. The message-handling step begins by verifying that themessage data corresponds to a valid message in step 496. In thepreferred embodiment, the message includes a cyclical redundancy check(CRC) by which the floor controller can determine whether the message isvalid or corrupt. Only if the message is valid will the floor controllerperform any additional message-handling steps. The floor controller alsoparses through the message in step 496 to determine what type themessage is. The message type determines the appropriate floor controlleraction. In the preferred embodiment, the messages include a command codewhich indicates the type of message.

[0240] The first type of message can be one which includes new meterinformation. The floor controller checks in step 498 to determinewhether the message includes this type of information. If the messageincludes new meter information, the floor controller saves the new meterinformation locally in step 500. The floor controller maintains localcopies of the meter information in order to minimize the amount oftraffic on the high-speed network. Because the machine meters change sorapidly, forwarding this new meter information on to the file servereach time one of these meters is altered would produce an excessiveamount of network traffic on the high-speed network. Therefore, in thepreferred embodiment, the floor controller saves this new meterinformation locally in step 500 and only forwards the new information onto the file server after a predetermined amount of time has elapsed.

[0241] Another type of message is one which requests data. The floorcontroller checks in step 502 to determine whether the message type isone requesting data. Typically, these data requests will be for playertracking information such as where a player inserts a card into a cardreader whereupon the data communication associated therewith sends theidentification number encoded on the card to the floor controllerrequesting the player tracking data associated with the playeridentification number. If the floor controller detects a data request instep 502, the floor controller looks up the requested data in thedatabase on the file server in step 504. Also, in step 504, the floorcontroller marks a response pending in the transactions in progressstructure to indicate that this requested data needs to be sent back tothe DCN. As described above, the floor controller queues up outgoingmessages responsive to the transactions in progress structure.

[0242] Another message type is one used by the floor controller toestablish new machine addresses. The floor controller periodicallychecks to determine whether any new DCN has been coupled to itsassociated current loop networks in order to assign a unique address tothat machine. In step 506, the floor controller checks to see whetherthe incoming message is in response to such a process. If the incomingmessage is in response to a machine search, the floor controller assignsa new machine address to the responding machine in step 508. The entireprocess of assigning new machine addresses is described below withreference to FIG. 31.

[0243] Finally, the floor controller in step 510 handles anymiscellaneous messages. These miscellaneous messages are used primarilyfor debugging and trouble-shooting the machines.

[0244] 3. Assigning Gaming Device Addresses

[0245] As described above, in the preferred embodiment of the invention,the floor controller uses a shorthand token representation of the DCN'sunique identification number to address the DCN. In the preferredembodiment, a single byte address is used to address a DCN on any givencurrent loop. This one-byte address allows up to 256 DCNs to besupported on any given current loop network. In the preferredembodiment, only 64 such DCNs are connected to a single current loopnetwork and therefore the single byte address is more than adequate. Thesingle byte address substantially reduces the amount of traffic on thecurrent loop network by reducing the number of bytes from four in theunique identification number to one for the shorthand tokenrepresentation.

[0246] The floor controller is responsible for generating the uniquesingle byte address for each data communication node on a given currentloop network. The process 508 of assigning unique addresses to the DCNson the current loop network is shown in FIG. 31. The process begins bydefining a range of unique identification numbers in step 512. Initiallythis will be a large range.

[0247] Next, the floor controller sends out a message to all of the DCNson the current loop network in step 514. The floor controllercommunicates with the DCNs by using a standard communication protocol.In the preferred embodiment, this protocol defines a message formatincluding a destination ID, a source ID, a message length, a data packetand a CRC. Other message formats could be used as well. Using thisformat, the floor controller can communicate with all of the DCNs on thecurrent loop network by using a global destination address in themessage. This global destination address would indicate to the DCNs thatthis message is intended for all DCNs on the current loop network. Thisglobal message would include two unique identification numbers that,taken together, define the range of unique identification numbersestablished in step 512.

[0248] The individual DCNs then checks to see whether their uniqueidentification number falls within this range. If a DCN's uniqueidentification number falls within this range and the DCN does not havean address assigned thereto, the DCN then responds to this globalmessage by sending a reply message in response that includes the uniqueidentification number of that DCN. In the event that more than one DCNhas a unique identification number that falls within this range anetwork collision will occur and the message will be corrupted. Theprocess 508 checks for this condition in step 516. This condition isindicated by an invalid CRC in the message.

[0249] In the event of a network collision, the floor controller canlimit the range of unique identification numbers by repeating step 512in the hope of eliminating this network contention.

[0250] If the response has a valid CRC, the floor controller assigns aunique address to the responding DCN, as identified by the uniqueidentification number in the response, in step 518. The floor controllerthen transmits this address along with the corresponding uniqueidentification number in an assignment message to all of the DCNs usinga global destination address in step 520. The DCNs then process thismessage and in the event that the unique identification number includedin the message corresponds to the DCN's unique identification number,the DCN adopts the address included in the message. Once the DCN hasbeen assigned an address in this manner, the DCN will interpret allsubsequent messages having a destination address equal to the assignedDCN address as being directed to that DCN. The above-described addressassignment sequence is repeated for each of the remaining DCNs on thecurrent loop network in step 522. The floor controller continues thisprocess until the entire range of unique identification numbers has beencovered and no more network collisions occur.

[0251] 4. System Monitoring

[0252] Referring now to FIG. 32, the system monitoring step 474 will nowbe described. The floor controller is now responsible for monitoringcertain system-wide conditions to determine whether certain events needto occur. The system monitoring step also handles request for particularmachine information. Thus, in step 524, the floor controller determineswhether a new request has been placed in the data base for suchparticular machine information. If such a request has been placed, thefloor controller responds to the special request for data in step 526 bysending a message to the particular machine requesting the requiredinformation. Once the required information has been received, the floorcontroller processes this information accordingly.

[0253] The floor controller also monitors the locally-stored meterinformation in step 528. If the locally-stored information is changed,the floor controller saves the latest information to the data base instep 530. As described above, the floor controller saves the meterinformation locally in order to minimize the traffic to the file serverover the high speed network.

[0254] The floor controller also monitors the system for certain eventtriggers in step 532. These triggers can be stored in the data base andfetched by the floor controller during its power-up procedures. Thesetriggers indicate if and when certain events occur. Examples of eventtriggers include: the drop period, the end-of-day, the bonus period,etc. If an event trigger has occurred, the floor controller handles theevent in step 534.

[0255] The handle event step 534 is shown in more detail in FIG. 33. Theevents can basically be bifurcated into accounting events and bonusingevents. Accounting events refer to the data communication activity ofthe system. The accounting events are typically triggered by a certaintime of day such as the end of day or the drop period. If an accountingevent has been triggered, the floor controller performs the requireddata base operations in step 538. This step involves updating all of thelocally-stored meter information and storing the updated meterinformation into the data base.

[0256] The other type of event can be referred to as a bonusing event.The floor controller checks to see whether the event is a bonusing eventin step 540. The bonusing events can also be triggered by the time ofday. For example, the bonusing event may be triggered from midnight to4:00 a.m. on weekdays. These bonusing periods can be specified in thedata base. If the triggered, event is a bonusing event, the floorcontroller inserts a corresponding reconfiguration message in the outputmessage queue in step 542. The reconfiguration message includes areconfiguration command that is sent to an appropriate machine. Themachine, upon receiving the reconfiguration command, reconfigures itspayout schedule in accordance with the received reconfiguration command.According to the invention, there are many different reconfigurationcommands to implement a multiplicity of different bonusing events. Onereconfiguration command specifies that the machine should reconfigureits payout schedule to be a multiple of its default payout schedule.This reconfiguration command can also specify that the multiple payoutschedule should be limited to a predetermined percentage of the coinsin. This reconfiguration command can further specify that the multiplepayout schedule should be limited to only when the maximum coins areplayed. This reconfiguration command can further specify that themultiple payout schedule should be limited to payouts in a specifiedrange. This reconfiguration command can also specify the multiple payoutschedule should payout only when a predetermined level of playeractivity is reached.

[0257] Another reconfiguration command allows any number of machines onthe network to be combined in a common jackpot having a common jackpotpayout schedule, wherein the reconfiguration command reconfigures theselected machines to payout in accordance with the common jackpot payoutschedule. In this case, the reconfiguration message would be queued upfor each of the selected machines to be combined in a common jackpot.One example of a common jackpot is a progressive jackpot. Unlike theprior art progressive jackpot systems, however, the progressive jackpotaccording to the invention is not limited to a predetermined number ofmachines. In the prior art progressive jackpot systems, a bank ofmachines are connected to a common progressive jackpot controller andonly those machines can be included in the progressive jackpot. Incontrast, any machine on the network, including those connected to otherfloor controllers can be combined into a common progressive jackpot.Moreover, the number of progressive jackpots is not limited by thenumber of floor controllers since one floor controller can manage morethan one progressive jackpot.

[0258] Another reconfiguration command permits the system to implementso-called “automatic mystery jackpots.” These “mystery” jackpots allow amachine to payout a mystery jackpot even when a jackpot was not won.Instead, the reconfiguration command can specify that the mysteryjackpot is to occur after a certain number of coins, a certain number ofhandle pulls, or a variety of other conditions specified by thereconfiguration commands. These mystery bonuses provide the casino withanother way to induce additional gaming activity.

[0259] 5. BONUS CONTROL

[0260] Referring now to FIG. 34, a method 550 for controlling theconditions under which the above-described bonus activities areactivated is shown. It is essential for the system to have completecontrol over the amount and conditions under which a bonus is paid outin order to insure the profitability of the bonusing system. The method550 described below provides the required control.

[0261] The method 550 begins in step 552 by disabling or turning off thebonuses in the individual machines. This is accomplished by sending amessage to the individual DCNs to turn off or deactivate bonusing. Next,the floor controller monitors the activities of the individual machinesconnected thereto. This step includes monitoring the coins in andbonuses paid for the individual machines, as described above. In step556, the floor controller modifies a bonus pool by a predeterminedpercentage of all coins played. The bonus pool is essentially a pool ofmonetary resources that can be allocated for bonus awards. In thepreferred embodiment, a predetermined percentage of the monetary valueof the coins played are added to the bonus pool. Also in this step, anybonuses paid by the gaming devices are also measured and subtracted fromthe bonus pool. The use of the bonus pool will become more apparent whenthe other steps are described hereinbelow.

[0262] In step 558, the floor controller determines whether or notbonusing is active. If bonusing is active, the floor controller nextdetermines whether the bonus pool amount has dropped below apredetermined minimum level called the “turn-off” level in 560. Thisminimum amount or floor can be set by the casino and provides a bufferto account for large bonus awards and/or multiple bonus awards thatcould cause the bonus payout to exceed the bonus pool. Therefore, if thebonus pool drops below the turn-off level, the method 550 branches backto step 552 and turns off bonusing. As will described further below, thebonusing remains off until such time as the bonus pool builds up pastanother minimum level called the “turn-on” level.

[0263] Returning to step 558, if the bonus is currently not active, thefloor controller determines at step 562 whether the bonus pool hasreached a predetermined turn-on level. This turn-on level can also beset by the casino and provides a buffer above the turn-off level toinsure that the bonusing does not behave erratically, i.e., bonusingrapidly switching between on and off. If the bonus pool is not above theturn-on level, bonusing is again turned off in step 552.

[0264] If the bonus pool has reached the turn-on level, the floorcontroller checks to see whether other bonus conditions are met at step564. These bonus conditions can include, but are not limited to, aminimum period of time since the last bonus activation, a minimum levelof play in the time period prior to the bonus pool reaching the turn onlevel, a predetermined time of day, or other predetermined conditions.These conditions give the casino additional control over the bonusingpromotions. If the conditions are not met, the method 550 branches backto step 552 where the bonusing is again turned off. If, however, theconditions are met in step 564, the bonus is turned on at step 566 andthe method 550 branches to step 554 where the machine activity is againmonitored.

[0265] In the preferred embodiment, the method 550 is embodied insoftware that is executed by each of the floor controllers in thesystem. These floor controllers are then responsible for activating ordeactivating the bonusing for the individual machines connected thereto.The system allows the floor controller to have multiple bonus pools andto have certain of the machines associated with a given bonus pool.Thus, the floor controller can implement multiple bonusing promotionssimultaneously.

[0266] This system also allows for machines connected to different floorcontrollers to be combined into a single bonusing promotion. In thiscase, one of the floor controllers assumes primary responsibility formanaging the bonus pool while the other floor controllers act asintermediaries between the primary floor controller and the machinesconnected to the other floor controllers. Thus, the system according tothe invention allows for much greater flexibility in running bonusingpromotionals than heretofore possible. Prior art systems requiredcertain predetermined machines to be connected into a bank for any givenbonus award such as a progressive bonus. The system according to theinvention allows any machine in the casino to be combined in a bonustype situation. The system also insures that the bonusing promotionalswill operate substantially in the black, i.e., the bonus pool is greaterthan the bonus payouts.

[0267] Having described and illustrated the principles of the inventionin a preferred embodiment thereof, it should be apparent that theinvention can be modified in arrangement and detail without departingfrom such principles. For example, although an Ethernet network wasdescribed in the preferred embodiment of the invention, other high-speednetworks such as wireless networks could be used in place thereof. Iclaim all modifications and variation coming within the spirit and scopeof the following claims.

1. A method of operating gaming devices interconnected by a computernetwork to a host computer comprising: sending a reconfiguration commandfrom the host computer to a gaming device over the network; receivingthe reconfiguration command at the gaming device; and reconfiguring thegaming device responsive to the received reconfiguration command,wherein the gaming device reconfigures its payout schedule in accordancewith the received reconfiguration command.
 2. A method of operatinggaming devices according to claim 1 wherein the step of reconfiguringthe gaming device includes reconfiguring the payout to be a multiple ofa default payout schedule.
 3. A method of operating gaming devicesaccording to claim 2 wherein the step of reconfiguring the gaming deviceincludes reconfiguring the payout to be double the default payoutschedule.
 4. A method of operating gaming devices according to claim 2wherein the step of reconfiguring the gaming device includes limitingthe multiple payout schedule to a predetermined percentage of the totalgaming device handle.
 5. A method of operating gaming devices accordingto claim 2 wherein the step of reconfiguring the gaming device includeslimiting the multiple payout schedule to a predetermined percentage ofthe coins in.
 6. A method of operating gaming devices according to claim2 wherein the step of reconfiguring the gaming device includes limitingthe multiple payout schedule to payout only when maximum coins areplayed.
 7. A method of operating gaming devices according to claim 2wherein the step of reconfiguring the gaming device includes limitingthe multiple payout schedule to payout only when an award falls within apredetermined range.
 8. A method of operating gaming devices accordingto claim 2 wherein the step of reconfiguring the gaming device includeslimiting the multiple payout schedule to payout only when apredetermined level of activity is reached.
 9. A method of operatinggaming devices according to claim 1 further comprising: selecting two ormore gaming devices on the network to be combined in a common jackpothaving a common jackpot payout schedule; wherein the step of sending areconfiguration command includes sending a reconfiguration command toeach of the selected gaming devices; and wherein the step ofreconfiguring the gaming device includes reconfiguring the selectedgaming devices to payout out in accordance with the common jackpotpayout schedule.
 10. A method of operating gaming devices according toclaim 9 wherein the step of reconfiguring the gaming device includesreconfiguring the selected gaming devices to payout out in accordancewith the common, progressive jackpot payout schedule.
 11. A method ofoperating gaming devices according to claim 1 wherein the step ofsending a reconfiguration command includes sending a reconfigurationcommand describing a progressive jackpot payout schedule to each of theselected gaming devices.
 12. A method of operating gaming devicesaccording to claim 1 wherein the step of reconfiguring the gaming deviceincludes reconfiguring the payout to be an automatic mystery payout. 13.A method of operating gaming devices according to claim 12 wherein thestep of sending a reconfiguration command from the host computer to agaming device via the network includes sending a reconfiguration commandspecifying the playing conditions under which the automatic mysterypayout will payout.
 14. A method of operating gaming devices accordingto claim 1 wherein the step of sending a reconfiguration command fromthe host computer to a gaming device via the network includes: detectingthe time of day; and sending the reconfiguration command from the hostcomputer to a gaming device via the network when the detected timeequals a predetermine time.
 15. A method of operating gaming devicesaccording to claim 14 further comprising inputting the predeterminedtime on the host computer.
 16. A method of operating gaming devicesaccording to claim 1 further comprising: sending a status request fromthe host computer to a gaming device; and transmitting accounting datafrom the gaming device to the host computer.
 17. A method of operatinggaming devices according to claim 16 further comprising: detecting aplayer associated with a gaming device; sending a player identificationnumber from the gaming device to the host computer over the network; andassociating the accounting data with the player identification numberfor player tracking purposes.
 18. A method of operating gaming devicesaccording to claim 17 further comprising: sending a command including acredit amount from the host computer to the gaming device associatedwith the player; and crediting the gaming device with the credit amountresponsive to receipt of the command to provide cashless play.
 19. Amethod of operating gaming devices interconnected by a computer networkto a host computer comprising: detecting a player associated with agaming device; sending a player identification number from the gamingdevice to the host computer over the network; sending a status requestfrom the host computer to a gaming device; transmitting accounting datafrom the gaming device to the host computer over the same network; andassociating the accounting data with the player identification numberfor player tracking purposes.
 20. A method of operating gaming devicesaccording to claim 19 further comprising reconfiguring a gaming deviceover the network, wherein the reconfigured gaming device modifies ajackpot payout schedule associated therewith.
 21. A method of operatinggaming devices interconnected by a computer network to a host computer,the method comprising: detecting a player associated with a gamingdevice; sending a reconfiguration command from the host computer to theplayer's gaming device via the network; receiving the reconfigurationcommand at the player's gaming device; and reconfiguring the player'sgaming device responsive to the received reconfiguration command,wherein the player's gaming device reconfigures its payout schedule inaccordance with the received reconfiguration command.
 22. A method ofoperating gaming devices according to claim 21 wherein the step ofreconfiguring the player's gaming device responsive to receipt of thereconfiguration command includes adding an extra bonus to the payoutschedule.
 23. A method of operating gaming devices according to claim 21wherein the step of reconfiguring the player's gaming device responsiveto receipt of the reconfiguration command includes adding a progressivejackpot to the payout schedule.
 24. A method of operating gaming devicesaccording to claim 21 further comprising determining whether the playersatisfies a predetermined criteria.
 25. A method of operating gamingdevices according to claim 24 wherein the step of determining whetherthe player satisfies a predetermined criteria includes determiningwhether the player is a member of a club.
 26. A method of operatinggaming devices according to claim 24 wherein the step of determiningwhether the player satisfies a predetermined criteria includesdetermining whether the player has reached a predetermined level ofactivity.
 27. A method of operating gaming devices according to claim 26wherein the step of determining whether the player has reached apredetermined level of activity includes: detecting the level ofactivity and the time period over which the activity occurs; andtransmitting the activity level and the time period to the host computervia the network.
 28. A system for operating a plurality of gamingdevices having serial interfaces, the system comprising: a hostcomputer; a network interconnecting the gaming devices to the hostcomputer; means within the computer for transmitting a reconfigurationcommand to a gaming device; means within each gaming device forreceiving the reconfiguration command transmitted to the gaming device;and means within each gaming device for reconfiguring the gaming deviceresponsive to the received reconfiguration command, wherein the gamingdevice reconfigures its payout schedule in accordance with the receivedreconfiguration command.
 29. A system for operating a plurality ofgaming devices according to claim 28 comprising: means within eachgaming device for identifying a player associated with each gamingdevice; means within each gaming device for sending the player identityfrom the player's gaming device to the host computer via the network;and means within the host computer for receiving the player identity.30. A system for operating a plurality of gaming devices according toclaim 29 wherein the means within the computer for transmitting areconfiguration command to each one of the gaming devices includes meanswithin the computer for transmitting a reconfiguration command to theplayer's gaming device responsive to the received player identity.
 31. Asystem for operating a plurality of gaming devices according to claim 28wherein the host computer comprises at least one floor controller.
 32. Asystem for operating a plurality of gaming devices according to claim 31wherein the host computer comprises a file server.
 33. A system foroperating a plurality of gaming devices according to claim 32 whereinthe network comprises: a current loop network coupled between the floorcontroller and a plurality of associated gaming devices; and ahigh-speed network coupled between the floor controller and the fileserver.
 34. A system for operating a plurality of gaming devicesaccording to claim 33 wherein the network includes a plurality ofcurrent loop networks, and wherein the floor controller includes acommunication board having a plurality of current loop interfaces forcoupling to the plurality of current loop networks, the communicationboard having a plurality of microprocessors, each microprocessorresponsible for the transmissions on an associated current loop network,the communication board including a current loop driver interposedbetween the plurality of microprocessors and the plurality of currentloop networks.
 35. A system for operating a plurality of gaming devicesaccording to claim 28 wherein the means within each gaming device forreceiving the reconfiguration command transmitted to the gaming devicecomprises a data communication node coupled to the network and coupledto the serial interface of the associated gaming device, wherein thedata communication node monitors the transmissions on the network anddetermines which transmission is transmitted to the associated gamingdevice.
 36. A system for operating a plurality of gaming devicesaccording to claim 35 wherein the data communication node includes: acontroller; a serial machine interface coupled between the controllerand the serial interface of the associated gaming device for receivingdata from the associated gaming device and transmitting the receivedreconfiguration command to the gaming device.
 37. A system for operatinga plurality of gaming devices according to claim 28 including anon-volatile memory within each gaming device for storing a uniquegaming device identification number to uniquely identify the gamingdevice on the network.
 38. A system for operating a plurality of gamingdevices according to claim 37 including: means within each gaming devicefor reading the unique gaming identification number; and means withineach gaming device for transmitting the unique gaming identificationnumber to the host computer.
 39. A system for operating a plurality ofgaming devices according to claim 37 including a machine configurationcircuit for identifying the type of gaming device.
 40. A method ofproviding feedback to a user inserting a user identification card havinga unique user identification number encoded thereon into a gamingdevice, the method comprising: receiving the card into a card readeropening; sensing the number on the card; determining whether the sensednumber is a valid identification number; and providing feedback to theuser adjacent the card reader opening, the feedback comprising apositive feedback signal if the sensed number is a valid identificationnumber and a negative feedback signal if the sensed number is not avalid identification number.
 41. A method of providing feedback to auser according to claim 40 wherein the step of providing feedback to theuser adjacent to the card reader opening includes providing visualfeedback around the card reader opening.
 42. A method of providingfeedback to a user according to claim 41 wherein the step of providingfeedback to the user adjacent to the card reader opening includesproviding a first visual signal having a first color if the sensednumber is a valid identification number and a second visual signalhaving a second color, different from the first color, if the sensednumber is not a valid identification number
 43. A method of providingfeedback to a user according to claim 42 wherein the step of providing afirst visual signal having a first color if the sensed number is a valididentification number includes providing a first visual signal having agreen color if the sensed number is a valid identification number; andwherein the step of providing a second visual signal having a secondcolor if the sensed number is not a valid identification number includesproviding a second visual signal having a red color if the sensed numberis not a valid identification number.
 44. A method of providing feedbackto a user according to claim 42 wherein the step of determining whetherthe sensed number is a valid identification number includes providing athird visual signal having a third color, different from the first andsecond colors, during the pendency of the determining step.
 45. A methodof providing feedback to a user according to claim 41 wherein the stepof providing feedback to the user adjacent to the card reader openingincludes actuating a plurality of light emitting diodes arranged aroundthe card reader opening.
 46. A method of providing feedback to a useraccording to claim 40 wherein the step of determining whether the sensednumber is a valid identification number includes comparing to aplurality of predetermined valid identification numbers.
 47. A cardreader having user feedback which reads a user identification cardhaving a user identification number encoded thereon comprising: a bezeldefining a card reader opening; means for sensing the useridentification number on the card; means for determining whether thesensed number is a valid identification number; and means for providingvisual feedback to the user adjacent the card reader opening, the visualfeedback comprising a first visual signal if the sensed number is avalid identification number and a second visual signal if the sensednumber is not a valid identification number.
 48. A card reader havinguser feedback according to claim 47 wherein the means for providingvisual feedback includes a plurality of light emitting diodes disposedaround the card reader opening.
 49. A card reader having user feedbackaccording to claim 48 wherein the light emitting diodes include duallight emitting diodes for producing both the first and the second visualsignals.
 50. A card reader having user feedback according to claim 47wherein the user identification card includes a plurality of holes whichencode the user identification number and which are arranged in columnsand wherein the means for sensing the user identification number on thecard includes an optical card reader.
 51. A card reader having userfeedback according to claim 50 wherein the optical card reader includes:a plurality of light emitting diodes disposed on a first side of thecard reader opening; and a plurality of photodetectors disposed on asecond side of the card, opposite the first side for detecting the lightemitted by the plurality of light emitting diodes.
 52. A card readerhaving user feedback according to claim 51 wherein the light emittingdiodes and the photodetectors are arranged in opposing pairs fordetecting the holes of a respective column.
 53. A card reader havinguser feedback according to claim 47 further including: means fordetecting the orientation of the card; and wherein the means fordetermining whether the sensed number is a valid identification numbertransposes the sensed number according to the orientation detected bythe detection means.
 54. A card reader having user feedback according toclaim 47 further including first and second guide members disposed onopposing lateral sides of the card reader opening for guiding a useridentification card therealong.
 55. A method of operating gaming devicesinterconnected by a computer network to a host computer comprising:monitoring the activity of the gaming devices; detecting the amount ofmoney played on the gaming devices; allocating a predeterminedpercentage of the money played to a bonus pool; determining the level ofthe bonus pool; and activating a bonus payout table in a gaming devicewhen the bonus pool level exceeds a turn-on level.
 56. A method ofoperating gaming devices interconnected by a computer network to a hostcomputer according to claim 55 comprising deactivating the bonus payouttable when the bonus pool falls below a turn-off level.
 57. A method ofoperating gaming devices interconnected by a computer network to a hostcomputer according to claim 55 comprising: determining the time periodsince the last bonus table activation; and deactivating the bonus payouttable when the time period exceeds a minimum period of time.
 58. Amethod of operating gaming devices interconnected by a computer networkto a host computer according to claim 55 comprising: determining thelevel of play for a gaming device; deactivating the bonus payout tablein the gaming device when the level of play falls below a predeterminedlevel.
 59. A method of operating gaming devices interconnected by acomputer network to a host computer according to claim 58 comprising:determining the time of day; deactivating the bonus payout table whenthe time of day is not within a predetermined period of time.
 60. Amethod of operating gaming devices interconnected by a computer networkto a host computer according to claim 55 comprising: detecting theamount of money paid out as bonuses on the gaming devices; modifying thebonus pool by the amount of money paid out as bonuses; determining thelevel of the bonus pool; and deactivating a bonus payout table in agaming device when the bonus pool level falls below a turn-off level.61. A method of operating gaming devices interconnected by a computernetwork to a host computer according to claim 60 wherein the turn-onlevel is above the turn-off level.